[ALL] Changing the commons process

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

[ALL] Changing the commons process

Charles Honton
Several recent email threads have discussed our parent pom and release process.  The process we have derive from Apache Common’s rich history which pre-dates many current distribution practices.  I’d like to summarize several quirks with our current releases:
The official release source tarball contains just the sources, not all the project files.  Building the artifact from just the src directory without the pom would be extremely difficult.
The commons parent pom attaches the source tarball to the maven release for the side effects of signing/checksumming the source tarball.  This induces a manual step of removing the source tarballs from the staging repository.
We publish convenience binaries to https://www.apache.org/dist/commons/XXX/binaries.  I doubt anyone consumes these binaries.  Most developers use Maven Central.  Extremely security conscious downstream projects consume the distribution source tarballs.
The distribution artifacts are doubled in size by providing both .zip and tar.gz versions.
Slightly different artifacts are published to Apache Distribution Site vs Maven Central.

Now the questions:

1. Are there any concerns with publishing the source and source-test jars produced by maven-source-plugin as the official distribution artifacts?  This would make the official distribution artifacts published to https://www.apache.org/dist/commons/XXX/source the same as the convenience source artifacts published to Maven Central.

2. Are there concerns with not publishing the convenience binaries to https://www.apache.org/dist/commons/XXX/binaries?  Alternatively, are there concerns with using the the jar produced by maven-jar-plugin as the convenience binary artifact?  This would make the convenience binary artifact published to https://www.apache.org/dist/commons/XXX/binaries the same as the convenience binary artifacts published to Maven Central.

Some background information to help contemplate these questions:

When releasing a package, Apache Commons publishes the official source tarball at https://www.apache.org/dist/commons/XXX/source.  The Apache Release Policy <http://www.apache.org/dev/release.html#what-must-every-release-contain> and Release Signing Policy <http://www.apache.org/dev/release-distribution.html#sigs-and-sums> require:
“Every ASF release must contain a source package, which must be sufficient for a user to build and test the release provided they have access to the appropriate platform and tools”
"Every artifact distributed to the public through Apache channels MUST be accompanied by one file containing an OpenPGP compatible ASCII armored detached signature and another file containing an MD5 checksum.” (.asc file and .md5 file)

Apache Commons also distributes convenience binaries at https://www.apache.org/dist/commons/XXX/binaries. These convenience binaries must also be signed and checksummed.

For even more convenience, Apache Commons also publishes packages to Maven Central.  Maven Central policy <http://central.sonatype.org/pages/requirements.html> requires:
“Projects with packaging other than pom have to supply JAR files that contain Javadoc and sources.”
“All files deployed need to be signed with GPG/PGP and a .asc file containing the signature must be included for each file.”
A pom file with
Correct Coordinates
Project Name, Description and URL
License Information
Developer Information
SCM Information
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Changing the commons process

Bernd Eckenfels
Am Fri, 23 Dec 2016 12:54:14 -0800
schrieb Charles Honton <[hidden email]>:

> The
> official release source tarball contains just the sources, not all
> the project files.  Building the artifact from just the src directory
> without the pom would be extremely difficult.

Can you name a component where this is true? Afaik all Commons
components have a full featured source archive which is buildable and a
limited source attachment for maven.

> The commons parent pom
> attaches the source tarball to the maven release for the side effects
> of signing/checksumming the source tarball.

Only for the -src classifier, this is Maven best practice since IDEs
can download and display this.

> This induces a manual
> step of removing the source tarballs from the staging repository.

I dont think removing them is the actual intention.

> We
> publish convenience binaries to
> https://www.apache.org/dist/commons/XXX/binaries.  I doubt anyone
> consumes these binaries.  Most developers use Maven Central.

This depends entirely on the project type they are used in. I would not
divert from this as it helps to actually find the artifacts and
especially release notes.

> Extremely security conscious downstream projects consume the
> distribution source tarballs. The distribution artifacts are doubled
> in size by providing both .zip and tar.gz versions.

Why would we care?

> Slightly
> different artifacts are published to Apache Distribution Site vs
> Maven Central.

Uh, how can that happen, the release process verifies the checksums.

Gruss
Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Changing the commons process

garydgregory
On Fri, Dec 23, 2016 at 1:06 PM, Bernd Eckenfels <[hidden email]>
wrote:

> Am Fri, 23 Dec 2016 12:54:14 -0800
> schrieb Charles Honton <[hidden email]>:
>
> > The
> > official release source tarball contains just the sources, not all
> > the project files.  Building the artifact from just the src directory
> > without the pom would be extremely difficult.
>

Incorrect.


>
> Can you name a component where this is true? Afaik all Commons
> components have a full featured source archive which is buildable and a
> limited source attachment for maven.
>

That true, the whole point of the *-src.zip and *-src.tar.gz files is to be
able to build from scratch.

The -sources jar in Maven Central are for IDEs, not for builds. These two
kinds of files are somewhat redundant.

Gary

>
> > The commons parent pom
> > attaches the source tarball to the maven release for the side effects
> > of signing/checksumming the source tarball.
>
> Only for the -src classifier, this is Maven best practice since IDEs
> can download and display this.
>
> > This induces a manual
> > step of removing the source tarballs from the staging repository.
>
> I dont think removing them is the actual intention.
>
> > We
> > publish convenience binaries to
> > https://www.apache.org/dist/commons/XXX/binaries.  I doubt anyone
> > consumes these binaries.  Most developers use Maven Central.
>
> This depends entirely on the project type they are used in. I would not
> divert from this as it helps to actually find the artifacts and
> especially release notes.
>
> > Extremely security conscious downstream projects consume the
> > distribution source tarballs. The distribution artifacts are doubled
> > in size by providing both .zip and tar.gz versions.
>
> Why would we care?
>
> > Slightly
> > different artifacts are published to Apache Distribution Site vs
> > Maven Central.
>
> Uh, how can that happen, the release process verifies the checksums.
>
> Gruss
> Bernd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Changing the commons process

garydgregory
In reply to this post by Charles Honton
On Fri, Dec 23, 2016 at 12:54 PM, Charles Honton <[hidden email]> wrote:

> Several recent email threads have discussed our parent pom and release
> process.  The process we have derive from Apache Common’s rich history
> which pre-dates many current distribution practices.  I’d like to summarize
> several quirks with our current releases:
> The official release source tarball contains just the sources, not all the
> project files.  Building the artifact from just the src directory without
> the pom would be extremely difficult.
> The commons parent pom attaches the source tarball to the maven release
> for the side effects of signing/checksumming the source tarball.  This
> induces a manual step of removing the source tarballs from the staging
> repository.
> We publish convenience binaries to https://www.apache.org/dist/
> commons/XXX/binaries.  I doubt anyone consumes these binaries.  Most
> developers use Maven Central.  Extremely security conscious downstream
> projects consume the distribution source tarballs.
> The distribution artifacts are doubled in size by providing both .zip and
> tar.gz versions.
> Slightly different artifacts are published to Apache Distribution Site vs
> Maven Central.
>
> Now the questions:
>
> 1. Are there any concerns with publishing the source and source-test jars
> produced by maven-source-plugin as the official distribution artifacts?


You cannot build from the -source jars so that would not work. We could ADD
stuff to these jars to make them the same as the -src.zip files. Then we do
not need the -src.zip/tar.gz files.



> This would make the official distribution artifacts published to
> https://www.apache.org/dist/commons/XXX/source the same as the
> convenience source artifacts published to Maven Central.
>
> 2. Are there concerns with not publishing the convenience binaries to
> https://www.apache.org/dist/commons/XXX/binaries?  Alternatively, are
> there concerns with using the the jar produced by maven-jar-plugin as the
> convenience binary artifact?  This would make the convenience binary
> artifact published to https://www.apache.org/dist/commons/XXX/binaries
> the same as the convenience binary artifacts published to Maven Central.
>

Since the binaries are conveniences, we can do whatever we want IMO.


>
> Some background information to help contemplate these questions:
>
> When releasing a package, Apache Commons publishes the official source
> tarball at https://www.apache.org/dist/commons/XXX/source.  The Apache
> Release Policy <http://www.apache.org/dev/release.html#what-must-every-
> release-contain> and Release Signing Policy <http://www.apache.org/dev/
> release-distribution.html#sigs-and-sums> require:
> “Every ASF release must contain a source package, which must be sufficient
> for a user to build and test the release provided they have access to the
> appropriate platform and tools”
> "Every artifact distributed to the public through Apache channels MUST be
> accompanied by one file containing an OpenPGP compatible ASCII armored
> detached signature and another file containing an MD5 checksum.” (.asc file
> and .md5 file)
>
> Apache Commons also distributes convenience binaries at
> https://www.apache.org/dist/commons/XXX/binaries. These convenience
> binaries must also be signed and checksummed.
>
> For even more convenience, Apache Commons also publishes packages to Maven
> Central.  Maven Central policy <http://central.sonatype.org/
> pages/requirements.html> requires:
> “Projects with packaging other than pom have to supply JAR files that
> contain Javadoc and sources.”
> “All files deployed need to be signed with GPG/PGP and a .asc file
> containing the signature must be included for each file.”
> A pom file with
> Correct Coordinates
> Project Name, Description and URL
> License Information
> Developer Information
> SCM Information


A lighter weight system would:

- Publish the same as we do now to Maven Central PLUS adding all of the
files needed to build to *-sources.jar files such that they become the same
as *-src.zip/*-src.tar.gz files.
- Publish the *-sources jar file to https://www.apache.org/dist/
commons/XXX/source instead of the *-src.zip/*-src.tar.gz files.
- Stop publishing *-bin files

The question is, if we publish a build-able *-source.jar file to
https://repository.apache.org/content/repositories/releases/org/apache/commons/,
why do we need to double that up and ALSO publish to
https://www.apache.org/dist/commons/XXX/source ?

Not publishing to https://www.apache.org/dist/commons/
<https://www.apache.org/dist/commons/XXX/source> would really simplify
things.

Gary



--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Changing the commons process

Bernd Eckenfels
Hello,
I think hybrid -sry/source does not work very well, since the IDE expect a package-like directory structure. I am not sure it would work with src/main/ prefix.

Gruss
Bernd
--
http://bernd.eckenfels.net




On Fri, Dec 23, 2016 at 11:33 PM +0100, "Gary Gregory" <[hidden email]> wrote:










On Fri, Dec 23, 2016 at 12:54 PM, Charles Honton  wrote:

> Several recent email threads have discussed our parent pom and release
> process.  The process we have derive from Apache Common’s rich history
> which pre-dates many current distribution practices.  I’d like to summarize
> several quirks with our current releases:
> The official release source tarball contains just the sources, not all the
> project files.  Building the artifact from just the src directory without
> the pom would be extremely difficult.
> The commons parent pom attaches the source tarball to the maven release
> for the side effects of signing/checksumming the source tarball.  This
> induces a manual step of removing the source tarballs from the staging
> repository.
> We publish convenience binaries to https://www.apache.org/dist/
> commons/XXX/binaries.  I doubt anyone consumes these binaries.  Most
> developers use Maven Central.  Extremely security conscious downstream
> projects consume the distribution source tarballs.
> The distribution artifacts are doubled in size by providing both .zip and
> tar.gz versions.
> Slightly different artifacts are published to Apache Distribution Site vs
> Maven Central.
>
> Now the questions:
>
> 1. Are there any concerns with publishing the source and source-test jars
> produced by maven-source-plugin as the official distribution artifacts?


You cannot build from the -source jars so that would not work. We could ADD
stuff to these jars to make them the same as the -src.zip files. Then we do
not need the -src.zip/tar.gz files.



> This would make the official distribution artifacts published to
> https://www.apache.org/dist/commons/XXX/source the same as the
> convenience source artifacts published to Maven Central.
>
> 2. Are there concerns with not publishing the convenience binaries to
> https://www.apache.org/dist/commons/XXX/binaries?  Alternatively, are
> there concerns with using the the jar produced by maven-jar-plugin as the
> convenience binary artifact?  This would make the convenience binary
> artifact published to https://www.apache.org/dist/commons/XXX/binaries
> the same as the convenience binary artifacts published to Maven Central.
>

Since the binaries are conveniences, we can do whatever we want IMO.


>
> Some background information to help contemplate these questions:
>
> When releasing a package, Apache Commons publishes the official source
> tarball at https://www.apache.org/dist/commons/XXX/source.  The Apache
> Release Policy  release-contain> and Release Signing Policy  release-distribution.html#sigs-and-sums> require:
> “Every ASF release must contain a source package, which must be sufficient
> for a user to build and test the release provided they have access to the
> appropriate platform and tools”
> "Every artifact distributed to the public through Apache channels MUST be
> accompanied by one file containing an OpenPGP compatible ASCII armored
> detached signature and another file containing an MD5 checksum.” (.asc file
> and .md5 file)
>
> Apache Commons also distributes convenience binaries at
> https://www.apache.org/dist/commons/XXX/binaries. These convenience
> binaries must also be signed and checksummed.
>
> For even more convenience, Apache Commons also publishes packages to Maven
> Central.  Maven Central policy  pages/requirements.html> requires:
> “Projects with packaging other than pom have to supply JAR files that
> contain Javadoc and sources.”
> “All files deployed need to be signed with GPG/PGP and a .asc file
> containing the signature must be included for each file.”
> A pom file with
> Correct Coordinates
> Project Name, Description and URL
> License Information
> Developer Information
> SCM Information


A lighter weight system would:

- Publish the same as we do now to Maven Central PLUS adding all of the
files needed to build to *-sources.jar files such that they become the same
as *-src.zip/*-src.tar.gz files.
- Publish the *-sources jar file to https://www.apache.org/dist/
commons/XXX/source instead of the *-src.zip/*-src.tar.gz files.
- Stop publishing *-bin files

The question is, if we publish a build-able *-source.jar file to
https://repository.apache.org/content/repositories/releases/org/apache/commons/,
why do we need to double that up and ALSO publish to
https://www.apache.org/dist/commons/XXX/source ?

Not publishing to https://www.apache.org/dist/commons/
 would really simplify
things.

Gary



--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory





Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Changing the commons process

Rob Tompkins
I would think we would want a release paradigm that is as similar to as many other projects as possible, for the sake of intuitive navigation of the project from the consumer perspective.

Might we look at some other large (Apache v. non-Apache and java v. non-java) projects to see how we stack up relative to them with our release artifacts?

-Rob

> On Dec 23, 2016, at 5:54 PM, Bernd Eckenfels <[hidden email]> wrote:
>
> Hello,
> I think hybrid -sry/source does not work very well, since the IDE expect a package-like directory structure. I am not sure it would work with src/main/ prefix.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
>
>
>
> On Fri, Dec 23, 2016 at 11:33 PM +0100, "Gary Gregory" <[hidden email]> wrote:
>
>
>
>
>
>
>
>
>
>
>> On Fri, Dec 23, 2016 at 12:54 PM, Charles Honton  wrote:
>>
>> Several recent email threads have discussed our parent pom and release
>> process.  The process we have derive from Apache Common’s rich history
>> which pre-dates many current distribution practices.  I’d like to summarize
>> several quirks with our current releases:
>> The official release source tarball contains just the sources, not all the
>> project files.  Building the artifact from just the src directory without
>> the pom would be extremely difficult.
>> The commons parent pom attaches the source tarball to the maven release
>> for the side effects of signing/checksumming the source tarball.  This
>> induces a manual step of removing the source tarballs from the staging
>> repository.
>> We publish convenience binaries to https://www.apache.org/dist/
>> commons/XXX/binaries.  I doubt anyone consumes these binaries.  Most
>> developers use Maven Central.  Extremely security conscious downstream
>> projects consume the distribution source tarballs.
>> The distribution artifacts are doubled in size by providing both .zip and
>> tar.gz versions.
>> Slightly different artifacts are published to Apache Distribution Site vs
>> Maven Central.
>>
>> Now the questions:
>>
>> 1. Are there any concerns with publishing the source and source-test jars
>> produced by maven-source-plugin as the official distribution artifacts?
>
>
> You cannot build from the -source jars so that would not work. We could ADD
> stuff to these jars to make them the same as the -src.zip files. Then we do
> not need the -src.zip/tar.gz files.
>
>
>
>> This would make the official distribution artifacts published to
>> https://www.apache.org/dist/commons/XXX/source the same as the
>> convenience source artifacts published to Maven Central.
>>
>> 2. Are there concerns with not publishing the convenience binaries to
>> https://www.apache.org/dist/commons/XXX/binaries?  Alternatively, are
>> there concerns with using the the jar produced by maven-jar-plugin as the
>> convenience binary artifact?  This would make the convenience binary
>> artifact published to https://www.apache.org/dist/commons/XXX/binaries
>> the same as the convenience binary artifacts published to Maven Central.
>>
>
> Since the binaries are conveniences, we can do whatever we want IMO.
>
>
>>
>> Some background information to help contemplate these questions:
>>
>> When releasing a package, Apache Commons publishes the official source
>> tarball at https://www.apache.org/dist/commons/XXX/source.  The Apache
>> Release Policy  release-contain> and Release Signing Policy  release-distribution.html#sigs-and-sums> require:
>> “Every ASF release must contain a source package, which must be sufficient
>> for a user to build and test the release provided they have access to the
>> appropriate platform and tools”
>> "Every artifact distributed to the public through Apache channels MUST be
>> accompanied by one file containing an OpenPGP compatible ASCII armored
>> detached signature and another file containing an MD5 checksum.” (.asc file
>> and .md5 file)
>>
>> Apache Commons also distributes convenience binaries at
>> https://www.apache.org/dist/commons/XXX/binaries. These convenience
>> binaries must also be signed and checksummed.
>>
>> For even more convenience, Apache Commons also publishes packages to Maven
>> Central.  Maven Central policy  pages/requirements.html> requires:
>> “Projects with packaging other than pom have to supply JAR files that
>> contain Javadoc and sources.”
>> “All files deployed need to be signed with GPG/PGP and a .asc file
>> containing the signature must be included for each file.”
>> A pom file with
>> Correct Coordinates
>> Project Name, Description and URL
>> License Information
>> Developer Information
>> SCM Information
>
>
> A lighter weight system would:
>
> - Publish the same as we do now to Maven Central PLUS adding all of the
> files needed to build to *-sources.jar files such that they become the same
> as *-src.zip/*-src.tar.gz files.
> - Publish the *-sources jar file to https://www.apache.org/dist/
> commons/XXX/source instead of the *-src.zip/*-src.tar.gz files.
> - Stop publishing *-bin files
>
> The question is, if we publish a build-able *-source.jar file to
> https://repository.apache.org/content/repositories/releases/org/apache/commons/,
> why do we need to double that up and ALSO publish to
> https://www.apache.org/dist/commons/XXX/source ?
>
> Not publishing to https://www.apache.org/dist/commons/
> would really simplify
> things.
>
> Gary
>
>
>
> --
> E-Mail: [hidden email] | [hidden email]
> Java Persistence with Hibernate, Second Edition
>
>
>
> JUnit in Action, Second Edition
>
>
>
> Spring Batch in Action
>
>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Changing the commons process

Charles Honton
In reply to this post by Bernd Eckenfels

I am incorrect about the contents of the sources zip.   It does contain all the files under source control.

As a test, I replaced ~/.m2/repository/org/apache/commons/commons-lang3/3.5/commons-lang3-3.5-src.jar with the distribution commons-lang3-3.5-src.zip.  Using the eclipse IDE, I navigated from the use of StringUtils.join() to its source.

I will test IntelliJ soon.  Are there any other IDEs that should be tested?  



> On Dec 23, 2016, at 2:54 PM, Bernd Eckenfels <[hidden email]> wrote:
>
> Hello,
> I think hybrid -sry/source does not work very well, since the IDE expect a package-like directory structure. I am not sure it would work with src/main/ prefix.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
> On Fri, Dec 23, 2016 at 11:33 PM +0100, "Gary Gregory" <[hidden email]> wrote:
>
> On Fri, Dec 23, 2016 at 12:54 PM, Charles Honton  wrote:
>
>> Several recent email threads have discussed our parent pom and release
>> process.  The process we have derive from Apache Common’s rich history
>> which pre-dates many current distribution practices.  I’d like to summarize
>> several quirks with our current releases:
>> The official release source tarball contains just the sources, not all the
>> project files.  Building the artifact from just the src directory without
>> the pom would be extremely difficult.
>> The commons parent pom attaches the source tarball to the maven release
>> for the side effects of signing/checksumming the source tarball.  This
>> induces a manual step of removing the source tarballs from the staging
>> repository.
>> We publish convenience binaries to https://www.apache.org/dist/
>> commons/XXX/binaries.  I doubt anyone consumes these binaries.  Most
>> developers use Maven Central.  Extremely security conscious downstream
>> projects consume the distribution source tarballs.
>> The distribution artifacts are doubled in size by providing both .zip and
>> tar.gz versions.
>> Slightly different artifacts are published to Apache Distribution Site vs
>> Maven Central.
>>
>> Now the questions:
>>
>> 1. Are there any concerns with publishing the source and source-test jars
>> produced by maven-source-plugin as the official distribution artifacts?
>
>
> You cannot build from the -source jars so that would not work. We could ADD
> stuff to these jars to make them the same as the -src.zip files. Then we do
> not need the -src.zip/tar.gz files.
>
>
>
>> This would make the official distribution artifacts published to
>> https://www.apache.org/dist/commons/XXX/source the same as the
>> convenience source artifacts published to Maven Central.
>>
>> 2. Are there concerns with not publishing the convenience binaries to
>> https://www.apache.org/dist/commons/XXX/binaries?  Alternatively, are
>> there concerns with using the the jar produced by maven-jar-plugin as the
>> convenience binary artifact?  This would make the convenience binary
>> artifact published to https://www.apache.org/dist/commons/XXX/binaries
>> the same as the convenience binary artifacts published to Maven Central.
>>
>
> Since the binaries are conveniences, we can do whatever we want IMO.
>
>
>>
>> Some background information to help contemplate these questions:
>>
>> When releasing a package, Apache Commons publishes the official source
>> tarball at https://www.apache.org/dist/commons/XXX/source.  The Apache
>> Release Policy  release-contain> and Release Signing Policy  release-distribution.html#sigs-and-sums> require:
>> “Every ASF release must contain a source package, which must be sufficient
>> for a user to build and test the release provided they have access to the
>> appropriate platform and tools”
>> "Every artifact distributed to the public through Apache channels MUST be
>> accompanied by one file containing an OpenPGP compatible ASCII armored
>> detached signature and another file containing an MD5 checksum.” (.asc file
>> and .md5 file)
>>
>> Apache Commons also distributes convenience binaries at
>> https://www.apache.org/dist/commons/XXX/binaries. These convenience
>> binaries must also be signed and checksummed.
>>
>> For even more convenience, Apache Commons also publishes packages to Maven
>> Central.  Maven Central policy  pages/requirements.html> requires:
>> “Projects with packaging other than pom have to supply JAR files that
>> contain Javadoc and sources.”
>> “All files deployed need to be signed with GPG/PGP and a .asc file
>> containing the signature must be included for each file.”
>> A pom file with
>> Correct Coordinates
>> Project Name, Description and URL
>> License Information
>> Developer Information
>> SCM Information
>
>
> A lighter weight system would:
>
> - Publish the same as we do now to Maven Central PLUS adding all of the
> files needed to build to *-sources.jar files such that they become the same
> as *-src.zip/*-src.tar.gz files.
> - Publish the *-sources jar file to https://www.apache.org/dist/
> commons/XXX/source instead of the *-src.zip/*-src.tar.gz files.
> - Stop publishing *-bin files
>
> The question is, if we publish a build-able *-source.jar file to
> https://repository.apache.org/content/repositories/releases/org/apache/commons/,
> why do we need to double that up and ALSO publish to
> https://www.apache.org/dist/commons/XXX/source ?
>
> Not publishing to https://www.apache.org/dist/commons/
> would really simplify
> things.
>
> Gary

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Changing the commons process

garydgregory
On Fri, Dec 23, 2016 at 4:02 PM, Charles Honton <[hidden email]> wrote:

>
> I am incorrect about the contents of the sources zip.   It does contain
> all the files under source control.
>
> As a test, I replaced ~/.m2/repository/org/apache/
> commons/commons-lang3/3.5/commons-lang3-3.5-src.jar with the distribution
> commons-lang3-3.5-src.zip.  Using the eclipse IDE, I navigated from the use
> of StringUtils.join() to its source.
>
> I will test IntelliJ soon.  Are there any other IDEs that should be tested?
>

NetBeans?

G


>
>
>
> > On Dec 23, 2016, at 2:54 PM, Bernd Eckenfels <[hidden email]>
> wrote:
> >
> > Hello,
> > I think hybrid -sry/source does not work very well, since the IDE expect
> a package-like directory structure. I am not sure it would work with
> src/main/ prefix.
> >
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> >
> > On Fri, Dec 23, 2016 at 11:33 PM +0100, "Gary Gregory" <
> [hidden email]> wrote:
> >
> > On Fri, Dec 23, 2016 at 12:54 PM, Charles Honton  wrote:
> >
> >> Several recent email threads have discussed our parent pom and release
> >> process.  The process we have derive from Apache Common’s rich history
> >> which pre-dates many current distribution practices.  I’d like to
> summarize
> >> several quirks with our current releases:
> >> The official release source tarball contains just the sources, not all
> the
> >> project files.  Building the artifact from just the src directory
> without
> >> the pom would be extremely difficult.
> >> The commons parent pom attaches the source tarball to the maven release
> >> for the side effects of signing/checksumming the source tarball.  This
> >> induces a manual step of removing the source tarballs from the staging
> >> repository.
> >> We publish convenience binaries to https://www.apache.org/dist/
> >> commons/XXX/binaries.  I doubt anyone consumes these binaries.  Most
> >> developers use Maven Central.  Extremely security conscious downstream
> >> projects consume the distribution source tarballs.
> >> The distribution artifacts are doubled in size by providing both .zip
> and
> >> tar.gz versions.
> >> Slightly different artifacts are published to Apache Distribution Site
> vs
> >> Maven Central.
> >>
> >> Now the questions:
> >>
> >> 1. Are there any concerns with publishing the source and source-test
> jars
> >> produced by maven-source-plugin as the official distribution artifacts?
> >
> >
> > You cannot build from the -source jars so that would not work. We could
> ADD
> > stuff to these jars to make them the same as the -src.zip files. Then we
> do
> > not need the -src.zip/tar.gz files.
> >
> >
> >
> >> This would make the official distribution artifacts published to
> >> https://www.apache.org/dist/commons/XXX/source the same as the
> >> convenience source artifacts published to Maven Central.
> >>
> >> 2. Are there concerns with not publishing the convenience binaries to
> >> https://www.apache.org/dist/commons/XXX/binaries?  Alternatively, are
> >> there concerns with using the the jar produced by maven-jar-plugin as
> the
> >> convenience binary artifact?  This would make the convenience binary
> >> artifact published to https://www.apache.org/dist/commons/XXX/binaries
> >> the same as the convenience binary artifacts published to Maven Central.
> >>
> >
> > Since the binaries are conveniences, we can do whatever we want IMO.
> >
> >
> >>
> >> Some background information to help contemplate these questions:
> >>
> >> When releasing a package, Apache Commons publishes the official source
> >> tarball at https://www.apache.org/dist/commons/XXX/source.  The Apache
> >> Release Policy  release-contain> and Release Signing Policy
> release-distribution.html#sigs-and-sums> require:
> >> “Every ASF release must contain a source package, which must be
> sufficient
> >> for a user to build and test the release provided they have access to
> the
> >> appropriate platform and tools”
> >> "Every artifact distributed to the public through Apache channels MUST
> be
> >> accompanied by one file containing an OpenPGP compatible ASCII armored
> >> detached signature and another file containing an MD5 checksum.” (.asc
> file
> >> and .md5 file)
> >>
> >> Apache Commons also distributes convenience binaries at
> >> https://www.apache.org/dist/commons/XXX/binaries. These convenience
> >> binaries must also be signed and checksummed.
> >>
> >> For even more convenience, Apache Commons also publishes packages to
> Maven
> >> Central.  Maven Central policy  pages/requirements.html> requires:
> >> “Projects with packaging other than pom have to supply JAR files that
> >> contain Javadoc and sources.”
> >> “All files deployed need to be signed with GPG/PGP and a .asc file
> >> containing the signature must be included for each file.”
> >> A pom file with
> >> Correct Coordinates
> >> Project Name, Description and URL
> >> License Information
> >> Developer Information
> >> SCM Information
> >
> >
> > A lighter weight system would:
> >
> > - Publish the same as we do now to Maven Central PLUS adding all of the
> > files needed to build to *-sources.jar files such that they become the
> same
> > as *-src.zip/*-src.tar.gz files.
> > - Publish the *-sources jar file to https://www.apache.org/dist/
> > commons/XXX/source instead of the *-src.zip/*-src.tar.gz files.
> > - Stop publishing *-bin files
> >
> > The question is, if we publish a build-able *-source.jar file to
> > https://repository.apache.org/content/repositories/releases/
> org/apache/commons/,
> > why do we need to double that up and ALSO publish to
> > https://www.apache.org/dist/commons/XXX/source ?
> >
> > Not publishing to https://www.apache.org/dist/commons/
> > would really simplify
> > things.
> >
> > Gary
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Changing the commons process

Jörg Schaible
In reply to this post by Charles Honton
Hi Charles,

Charles Honton wrote:

> I am incorrect about the contents of the sources zip.   It does contain
> all the files under source control.
>
> As a test, I replaced
> ~/.m2/repository/org/apache/commons/commons-lang3/3.5/commons-lang3-3.5-
src.jar

??

The default release profile of Maven normally produces an <artifactId>-
sources.jar containing the plain sources and resources. This is a defacto
standard ... you can check that looking at search.maven.org.

> with the distribution commons-lang3-3.5-src.zip.  Using the eclipse IDE, I
> navigated from the use of StringUtils.join() to its source.

The <artifactId>-src.zip and <artifactId>-src.tar.gz are the source
artifacts we provide in Apache's download area. Each must contain everything
to build the release. This is what we effectively vote on. Anything else is
just for convenience of our clients (including the complete stuff in the
Maven repository).

> I will test IntelliJ soon.  Are there any other IDEs that should be
> tested?

If we continue to provide our artifacts on Maven central for convenience
then we should also match the standards. Anything else does not make sense.

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Changing the commons process

Jörg Schaible
In reply to this post by garydgregory
Gary Gregory wrote:

> On Fri, Dec 23, 2016 at 1:06 PM, Bernd Eckenfels <[hidden email]>

[snip]

>> Can you name a component where this is true? Afaik all Commons
>> components have a full featured source archive which is buildable and a
>> limited source attachment for maven.
>>
>
> That true, the whole point of the *-src.zip and *-src.tar.gz files is to
> be able to build from scratch.
>
> The -sources jar in Maven Central are for IDEs, not for builds. These two
> kinds of files are somewhat redundant.

They are a defacto standard in the Maven repository, because of the standard
release profile of Maven.

Cheers,
Jörg



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Changing the commons process

Charles Honton
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 <http://svn.apache.org/viewvc/maven/pom/trunk/asf/pom.xml?view=markup> contains the following:
    <!-- START SNIPPET: release-profile -->
    <profile>
      <id>apache-release</id>
      <build>
        <plugins>
          <!-- Create a source-release artifact that contains the fully buildable
               project directory source structure. This is the artifact which is
               the official subject of any release vote. -->
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-assembly-plugin</artifactId>
            <dependencies>
              <dependency>
                <groupId>org.apache.apache.resources</groupId>
                <artifactId>apache-source-release-assembly-descriptor</artifactId>
                <version>1.0.6</version>
              </dependency>
            </dependencies>
            <executions>
              <execution>
                <id>source-release-assembly</id>
                <phase>package</phase>
                <goals>
                  <goal>single</goal>
                </goals>
                <configuration>
                  <runOnlyAtExecutionRoot>true</runOnlyAtExecutionRoot>
                  <descriptorRefs>
                    <descriptorRef>source-release</descriptorRef>
                  </descriptorRefs>
                  <tarLongFileMode>posix</tarLongFileMode>
                </configuration>
              </execution>
            </executions>
          </plugin>
          <!-- We want to deploy the artifact to a staging location for perusal -->
          <plugin>
            <inherited>true</inherited>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-deploy-plugin</artifactId>
            <configuration>
              <updateReleaseInfo>true</updateReleaseInfo>
            </configuration>
          </plugin>
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-source-plugin</artifactId>
            <executions>
              <execution>
                <id>attach-sources</id>
                <goals>
                  <goal>jar-no-fork</goal>
                </goals>
              </execution>
            </executions>
          </plugin>
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-javadoc-plugin</artifactId>
            <executions>
              <execution>
                <id>attach-javadocs</id>
                <goals>
                  <goal>jar</goal>
                </goals>
              </execution>
            </executions>
          </plugin>
          <!-- We want to sign the artifact, the POM, and all attached artifacts -->
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-gpg-plugin</artifactId>
            <executions>
              <execution>
                <id>sign-release-artifacts</id>
                <goals>
                  <goal>sign</goal>
                </goals>
              </execution>
            </executions>
          </plugin>
        </plugins>
      </build>
    </profile>
    <!-- END SNIPPET: release-profile -->
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Changing the commons process

Ralph Goers
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 <[hidden email]> 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 <http://svn.apache.org/viewvc/maven/pom/trunk/asf/pom.xml?view=markup> contains the following:
>    <!-- START SNIPPET: release-profile -->
>    <profile>
>      <id>apache-release</id>
>      <build>
>        <plugins>
>          <!-- Create a source-release artifact that contains the fully buildable
>               project directory source structure. This is the artifact which is
>               the official subject of any release vote. -->
>          <plugin>
>            <groupId>org.apache.maven.plugins</groupId>
>            <artifactId>maven-assembly-plugin</artifactId>
>            <dependencies>
>              <dependency>
>                <groupId>org.apache.apache.resources</groupId>
>                <artifactId>apache-source-release-assembly-descriptor</artifactId>
>                <version>1.0.6</version>
>              </dependency>
>            </dependencies>
>            <executions>
>              <execution>
>                <id>source-release-assembly</id>
>                <phase>package</phase>
>                <goals>
>                  <goal>single</goal>
>                </goals>
>                <configuration>
>                  <runOnlyAtExecutionRoot>true</runOnlyAtExecutionRoot>
>                  <descriptorRefs>
>                    <descriptorRef>source-release</descriptorRef>
>                  </descriptorRefs>
>                  <tarLongFileMode>posix</tarLongFileMode>
>                </configuration>
>              </execution>
>            </executions>
>          </plugin>
>          <!-- We want to deploy the artifact to a staging location for perusal -->
>          <plugin>
>            <inherited>true</inherited>
>            <groupId>org.apache.maven.plugins</groupId>
>            <artifactId>maven-deploy-plugin</artifactId>
>            <configuration>
>              <updateReleaseInfo>true</updateReleaseInfo>
>            </configuration>
>          </plugin>
>          <plugin>
>            <groupId>org.apache.maven.plugins</groupId>
>            <artifactId>maven-source-plugin</artifactId>
>            <executions>
>              <execution>
>                <id>attach-sources</id>
>                <goals>
>                  <goal>jar-no-fork</goal>
>                </goals>
>              </execution>
>            </executions>
>          </plugin>
>          <plugin>
>            <groupId>org.apache.maven.plugins</groupId>
>            <artifactId>maven-javadoc-plugin</artifactId>
>            <executions>
>              <execution>
>                <id>attach-javadocs</id>
>                <goals>
>                  <goal>jar</goal>
>                </goals>
>              </execution>
>            </executions>
>          </plugin>
>          <!-- We want to sign the artifact, the POM, and all attached artifacts -->
>          <plugin>
>            <groupId>org.apache.maven.plugins</groupId>
>            <artifactId>maven-gpg-plugin</artifactId>
>            <executions>
>              <execution>
>                <id>sign-release-artifacts</id>
>                <goals>
>                  <goal>sign</goal>
>                </goals>
>              </execution>
>            </executions>
>          </plugin>
>        </plugins>
>      </build>
>    </profile>
>    <!-- END SNIPPET: release-profile -->



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Changing the commons process

Bernd Eckenfels
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" <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]






Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Changing the commons process

sebb-2-2
On 25 December 2016 at 04:15, Bernd Eckenfels <[hidden email]> 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" <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]