commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [ALL] Changing the commons process
Date Sun, 25 Dec 2016 19:28:05 GMT
On 25 December 2016 at 04:15, Bernd Eckenfels <ecki@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.goers@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message