Dear Wiki user, You have subscribed to a wiki page or wiki category on "Commons Wiki" for change notification.
The "ReleaseDeployment" page has been changed by sebbapache: https://wiki.apache.org/commons/ReleaseDeployment?action=diff&rev1=6&rev2=7 These are deployed to the Nexus staging area via Maven deploy. The staging area is then published in the VOTE e-mail. - If the RC vote succeeds, the staging area is promote to release state, and Nexus ensures that the artifacts are copied to Maven Central. + If the RC vote succeeds, the staging area is promoted to release state, and Nexus ensures that the artifacts are copied to Maven Central. If the RC vote fails, the staging area is deleted. == Current tarball process == @@ -85, +85 @@ Nexus Maven plugin seems not to work and the docs have not been updated recently. However, it is quite easy to use HTTP POST to upload a bundle to Nexus, and it's easy to create a bundle (basically just a jar of the files to be uploaded; no need for hashes, but sigs with a public id are needed). + Alternatively, deploy:deploy-file can be used to upload the main jar plus all the additional files (this is what deploy:deploy does internally, AFAICT). + + However when using either bundle upload or a generated deploy-file script there is a risk that some files might be omitted. + One can either use mvn deploy -Prelease -Ptest-deploy to create all the files, sigs and hashes under target/deploy. Or "mvn verify -Prelease" will create the files and sigs (but no hashes) under target. @@ -97, +101 @@ This can easily be done by defining '''-Dassembly.attach=false''' on the command-line or adding '''<attach>false</attach>''' to the plugin config in the '''release''' profile + The tarballs can then be created using: + + mvn assembly:single + + However it's not currently possible to use the gpg:sign plugin to sign them without first executing the package or verify phases. + But these phases always recreate the jars, so the assemblies would end up with different jars from Maven. + And potentially different classes as well, because incremental compilation is currently broken when package-info.java files are used. + === Advantages === * no need to copy/delete the tarballs from Nexus * SVN traceability of tarballs from dev to release folder + * the deploy plugin ensures only the correct artifacts are uploaded === Disadvantages === - * tarballs will need to be uploaded to https://dist.apache.org/repos/dist/dev/commons/<component> (will need script/new Maven plugin to do this) - * If RC fails, tarballs have to be removed - * if RC succeeds, tarballs still have to be moved from dist/dev to dist/release directory; this needs a script/plugin * will need to update pom(s) to sign the tarballs (hopefully just once in CP) * update poms to create the hashes (hopefully just once in CP) - * deploy still adds useless .asc hashes to the staging repo. + * tarballs will need to be uploaded to https://dist.apache.org/repos/dist/dev/commons/<component> (will need script/new Maven plugin to do this) + * If RC fails, tarballs have to be removed (easy enough to delete containing directory) + * if RC succeeds, tarballs still have to be moved from dist/dev to dist/release directory; this needs a script/plugin for svnmucc + * deploy still adds useless .asc hashes to the staging repo; however this bug might be fixed one day == Longshot: Update Nexus to allow it to stage tarballs as well as Maven jars == --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
