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)
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
