On 25 December 2016 at 04:15, Bernd Eckenfels <e...@zusammenkunft.net> wrote: > Hello Ralph, besides the strange .pgp.asc files (and I think some components > don't have that problem) the component releases should not need to actually > delete artifacts in the staged repo when running the documented release > goal/profile. > You can in the POM control what is attached for some plugins (like assembly) > and for others you could use the build helper to detach. > Are there any commons projects which requires manual deletes? We should fix > them not only to reduce work, but also to ensure a repeatable build. (This > does not look like a general process problem to me, it's more like POM > nuances)
The ASF release artifacts must be signed and hashed. AIUI that requires them to be attached to the build, which in turn causes them to be uploaded to Nexus staging. Maybe it's possible to control those two operations independently; I don't know enough Maven. In any case, the artifacts need to be generated, signed+hashed, and then uploaded to dist/dev for the release vote. One way to do this is via the Nexus staging site. > Gruss > Bernd > -- > http://bernd.eckenfels.net > > > > > On Sun, Dec 25, 2016 at 12:02 AM +0100, "Apache" <ralph.go...@dslextreme.com> > wrote: > > > > > > > > > > > Maven is going to publish all the artifacts that are built to the repository. > This isn’t necessarily a bad thing as people can look at them all in one > place during the vote. But after the vote is approved anything that a user > wouldn’t ever want in a maven build should be deleted before the release > button is pushed. This includes things like examples and the whole > distribution. During the vote the release manager should be downloading > everything from the repository so he can validate the build any way. It is a > simple matter to take the distribution files and commit them where they > belong. > > All the things you are discussion here are what I have been dealing with for > the last several years in Log4j 2. The steps in the release process aren’t > what cause me pain. It is simply the time it takes to run a release build, > verify it, fix any problems, and then run it again as needed - all of which I > do before I send out a vote email. I don’t really see any way to make that > shorter. > > Ralph > >> On Dec 24, 2016, at 3:28 PM, Charles Honton wrote: >> >> I tested IDEs with a non-standard packaging of -sources.jar; java sources >> were inside of src/main/java/ folder. >> - Eclipse was able to use. >> - IntelliJ was able to use with a few extra clicks. >> - Netbeans was NOT able to use. >> I don’t think this option should be pursued further. >> >> A better alternative to consider is what the maven projects do. They >> release a -source-release.zip at https://www.apache.org/dist/maven/ which is >> also pushed to maven central. This zip looks to be similar to a maven >> predefined ‘project’ assembly. >> >> The maven plugins inherited pom contains the following: >> >> >> apache-release >> >> >> >> >> org.apache.maven.plugins >> maven-assembly-plugin >> >> >> org.apache.apache.resources >> apache-source-release-assembly-descriptor >> 1.0.6 >> >> >> >> >> source-release-assembly >> package >> >> single >> >> >> true >> >> source-release >> >> posix >> >> >> >> >> >> >> true >> org.apache.maven.plugins >> maven-deploy-plugin >> >> true >> >> >> >> org.apache.maven.plugins >> maven-source-plugin >> >> >> attach-sources >> >> jar-no-fork >> >> >> >> >> >> org.apache.maven.plugins >> maven-javadoc-plugin >> >> >> attach-javadocs >> >> jar >> >> >> >> >> >> >> org.apache.maven.plugins >> maven-gpg-plugin >> >> >> sign-release-artifacts >> >> sign >> >> >> >> >> >> >> >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
