-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Publish license lists to maven central? #163
Comments
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. |
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/ Note that the tool may be configured as a Maven plugin as well, in which case there's no need to invoke |
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.
The text was updated successfully, but these errors were encountered: