Would you consider putting JMX exporter releases on Maven Central?

[jhominal]

Hello,

I am a user of the JMX exporter Java Agent, working in a company with significant security requirements, and as such access to Github is quite regulated. For me, the fact that the Java Agent was published on Maven Central had a few advantages:

• As we are working in a Java environment, we already have a mirror to Maven Central, with standard processes to handle update of dependencies, deprecation of old versions, tracking of security vulnerabilities - I could use the JMX exporter Java Agent in my build as "just another dependency", which made discussions with conformity easier. With Github Releases, if I want to download the artifact in my build environment, I will have to ask for a bespoke proxy (they do not want to open access to the whole of github.com), and I will have to ask through a manual process for every update;
• As long as the artifact group+name does not change, I can check for updates to jmx_exporter on Maven Central in the same way as I check for updates to any of my library dependencies, in a fully automated way - if I want to automate watching of Github releases, I need to ask for a firewall rule to access Github API, manage an Github API account and token for automation, etc. - there is nothing unfeasible, but it is all extra work that has to be handled and maintained;

In short, the fact that the JMX exporter was available on Maven Central was, in my opinion, a good thing in terms of convenience for enterprise users, and I am not sure why it had to go away in the last release (I have searched for an explanation in Github issues and PRs but could not find it.)

[dhoard]

@jhominal Here is some background about the current decision to publish the release using GitHub Releases...

• The JMX Exporter Java agent and standalone JMX Exporter jars are applications, not libraries. Maven Central is common for libraries, but much less common for applications.

• Publishing the artifacts to Maven Central implies that the code may be used in an application as a library. This usage is not supported/intended. We do publish the collector module to Maven Central, but we have a clear support statement.

  • Reference: https://prometheus.github.io/jmx_exporter/1.1.0/collector/

• Using Maven or Gradle dependency management for an application could result in people downloading updated jars without reading any documentation, release information, etc. and unintentionally breaking their usage.

• Publishing using GitHub Releases is consistent with other Prometheus exporters.

• The io.prometheus package coordinates have been moved from the OSSRH Maven Central hosting to Maven Central Portal hosting. A side effect is that we have no download metrics using Maven Central Portal hosting.

[jhominal]

Thank you for providing background on this decision!

In any case we were looking at integrating our application more deeply with prometheus metrics, and as we are using the JMX exporter mostly for JVM instrumentation, I think we will transition to using JVM instrumentation in java_client instead. (The JMX exporter makes more sense for an application that wants to stay completely agnostic from Prometheus, which is not the case for our application.)

Thank you for your work, and good luck. :)