-
Notifications
You must be signed in to change notification settings - Fork 84
Description
Currently, the plugin specifies a default version of the reachability metadata. If the user says nothing, we default to that version and try to fetch the metadata from the repository GitHub releases page.
However, the community has expressed interest in seeing that metadata published as a Maven artifact (that is to say, on Maven Central, in practice).
After discussions, the NBT team suggests that this project takes care of publishing such metadata on Maven Central, by publishing on Central the default version that we depend on.
In practice, I suggest to proceed with the following:
- add a Gradle task which is responsible for downloading the default version of the metadata repository
- convert that artifact into a
jarfile (because it's easier for Maven consumers to depend on ajarthan on azip) - publish that artifact as a classified artifact of the graalvm-reachability-metadata project
- change the default URL that we use in the plugin to use Maven Central's URL for that artifact
This can possibly require some changes in the project so that we can support jars as repository format.
In addition, this raises the question of the artifact name, because the metadata repository version is different from the NBT version. We could, for example, use this: https://repo1.maven.org/maven2/org/graalvm/buildtools/graalvm-reachability-metadata/0.9.14/graalvm-reachability-metadata-0.9.14-repository.jar, that is to say ignore the repository version. There is unfortunately no way we can encode the repository version in the artifact name while preserving the compatibility with the Maven repository format.
However, this complicates the semantics of the version property in the DSL: this property refers to the metadata repository version, not the NBT version. So by default, we would use the URL from Maven, but if the version is specified, we'd need to use the GH releases URL.
Note that this proposal doesn't change the fact that a user can specify a local file, or a full URL to a custom repository. This is really about shipping a metadata repository release as part of the NBT release, without embedding it into the NBT jar itself.
/cc @sdeleuze wdyt?