You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am presently exploring the utilization of JoularJX as an energy profiling tool for Java-based applications. Having meticulously delved into the project's source code after forking it, I have identified several crucial aspects that warrant discussion before implementing any modifications.
An imperative consideration revolves around establishing a mechanism for consumers to construct their extensions seamlessly integrating with the agent. Consequently, it becomes imperative to introduce Service Provider Interface (SPI) as a distinct entity. This will empower users to fashion extensions that seamlessly plug into the agent, such as developing an extension for data transmission to Prometheus or Grafana.
A corollary to the introduction of SPI is the necessitated modification of the existing code layout. This entails the creation of discrete Maven modules, each dedicated to distinct functionalities like SPI and the core, ensuring a modular and organized codebase.
Unifying the code formatting process is paramount to maintain a consistent and cohesive codebase. To this end, it is imperative that all contributors adhere to a shared code formatter, fostering a standardized approach to coding practices.
Observing the presence of numerous warnings within the workspace, it is prudent to address and eliminate these warnings, thereby enhancing the overall code quality and maintainability.
Proposing a noteworthy extension, the integration of OpenTelemetry/Micrometer or the introduction of an extension to facilitate data transmission to Grafana would undoubtedly augment the project's capabilities and relevance in a broader context.
A notable observation is the absence of the agent in Maven Central for wider accessibility. To rectify this, I suggest deploying both the agent and any prospective SPI extensions to Maven Central, ensuring seamless consumption by a broader audience.
I eagerly await your thoughts and feedback on these proposed ideas, as they aim to elevate the functionality, modularity, and accessibility of JoularJX.
The text was updated successfully, but these errors were encountered:
My goal here is to keep the Agent as light as possible, hence the modularity and opening to SPIs would be a good addition.
For telemetry (assuming it's just for easing energy statistics transmissions to Grafana and co.), I'm more open to an extension (through SPI for instance).
Good suggestion for Maven central inclusion, thanks!
As much as I would like to contribute, we do not have sufficient ressources to advance quickly on these modifications.
I'll be willing to review and discuss any PR or proposition you (or anyone in the community) is willing to provide. I could propose student projects or try to find funding for internship in our research group but they won't come until a few months.
@adelnoureddine Thanks a lot for your valuable feedback. I would try to work in my own fork and push the changes separately as soon as they are finished.
I am presently exploring the utilization of JoularJX as an energy profiling tool for Java-based applications. Having meticulously delved into the project's source code after forking it, I have identified several crucial aspects that warrant discussion before implementing any modifications.
I eagerly await your thoughts and feedback on these proposed ideas, as they aim to elevate the functionality, modularity, and accessibility of JoularJX.
The text was updated successfully, but these errors were encountered: