Extension: Publish Example Service to Maven
Description
blocks
is blocked by
is caused by
relates to
Confluence content
QAlity Plus - Test Management
Checklists
Activity
I believe we can take figuring out the signing key we want to use out of this ticket - so I am closing it.
Verified that the jars are published to OSS.
I've finished configuring openlmis-example job on Jenkins:
The snapshots are being published to https://oss.sonatype.org/content/repositories/snapshots/org/openlmis/openlmis-example/
The OSSRH credentials as well as GPG key id and password are saved on Jenkins (credentials plugin) and passed as environment variables to the builder.
secring.gpg file has to be located under .signing/ in the project root
If the credentials/key details are not provided, gradle will skip signing and publishing archives
@Josh Zamor Could you provide us with the old keyring (secring.gpg)?
Hi @Jakub Kondrat, yes we should sign the jars' on Jenkins. Can we do this with any old cert?
As for the version let's keep it at 0.0.1-SNAPSHOT. No need to associate it with the reference distribution version.
Looking at this issue there are two minor details that I didn't add:
1. The gradle task should only be used by Jenkins (i.e. username and password for OSSRH is only stored in Jenkins). In this way only Jenkins tasks may publish artifacts.
2. there is a difference in publishing snapshots and production releases to OSSRH, and so it follows that Jenkins will need to be able to determine this difference: it may only ever publish snapshots to snapshots (which may overwrite previous), and release to release (and only ever once).
If there are any questions please let me know.
@Josh Zamor Do we want to generate some common key for signing jars on Jenkins? Also which version should we use for openlmis-example: 0.0.1-SNAPSHOT, 1.0.0-SNAPSHOT or 3.0.0-SNAPSHOT?
Details
Details
Assignee
Paweł GesekReporter
Josh ZamorStory Points
Time tracking
Components
Sprint
Fix versions
Priority
Critical
Time Assistant
Open Time Assistant
Time Assistant
In previous work on Extension Modules and Points we've noted that we will need to publish a Service's relevant classes (at the very least Extension Points and supporting types) to Maven so that an Extension Module may declare that service code as a dependency and compile against it.
For more on Maven JAR requirements: http://central.sonatype.org/pages/ossrh-guide.html
Acceptance:
we have our namespace in the Maven central repository (@Josh Zamor to get this)
a JAR is generated or the Spring Boot JAR is as-is determined to be appropriate to deploy to Maven
a POM is created, potentially generated through https://docs.gradle.org/current/userguide/publishing_maven.html , the group id, artifact and version should come through Gradle.
there is a gradle task that publishes the correct JAR to the Maven Central Repository using the versioning information (group, artifact, version) already provided in Gradle. e.g. https://github.com/OpenLMIS/openlmis-requisition/blob/master/build.gradle#L23 and https://github.com/OpenLMIS/openlmis-requisition/blob/master/gradle.properties
the above solution is implemented in openlmis-example
another gradle project may declare the requisition service as a dependency with a line in it's build.gradle like: compile "org.openlmis:requisition:3.0.0-beta". Implement this in openlmis-example-extension and document this in the README
This story should likely be broken out