Open loosebazooka opened 1 year ago
I like this idea. It would help me keep the cached license list up to date in other libraries.
I'm manually publishing the SPDX libraries to Maven Central. @loosebazooka - do you know if there is a way to automate publishing - e.g. in a Github Action? If so, we could add that license-list-data Repo triggered on when a tag is created for release.
In the mean time, you could pull the latest tagged data from the license-list-data which would make it reproduceable.
In the mean time, you could pull the latest tagged data from the license-list-data which would make it reproduceable.
Yeah I think we'll do that.
There is automation, it requires you putting secrets in GHA. Maybe projects do it (https://docs.github.com/en/actions/publishing-packages/publishing-java-packages-with-maven#publishing-packages-to-the-maven-central-repository). There's also the option of using jreleaser here, which is a tool that is trying to make java releases easier.
Either that, or you could have a github tag/commit trigger a release from a CI system you fully control (if one exists).
Here are two additional resources that explain all the requirements for publishing to Maven Central using GitHub actions and JReleaser
https://maciejwalkowiak.com/blog/guide-java-publish-to-maven-central/ https://jreleaser.org/guide/latest/examples/maven/maven-central.html
Note that the tool may be configured as a Maven plugin as well, in which case there's no need to invoke jreleaser/release-action
but rather a plugin goal such as jreleaser:full-release
.
Thanks @aalmiray and @loosebazooka - I'll look into implementing this over the next few weeks after the SPDX 3.0 model release.
Could the license list be published to maven central as an artifact like
org.spdx:license-list:x.y.z
, presumably with all types embedded in it.This benefits the gradle/maven build ecocystems.
It would allow build system managed downloading and caching of the license list for use in the gradle/maven plugins. Also allows the build to be a bit more reproducible as it removes a dependency on a mutable remote object.
We have considered embedding the license list in the gradle plugin but if it changes frequently enough, that would trigger a requirement on rebuilding the plugin. With a separate licensesList dependency, this would be avoided.