Re: [ALL] Changing the commons process

On Fri, Dec 23, 2016 at 4:02 PM, 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

Re: [ALL] Changing the commons process

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

Re: [ALL] Changing the commons process

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

Re: [ALL] Changing the commons process

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"

Re: [ALL] Changing the commons process

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

Re: [ALL] Changing the commons process

On Fri, Dec 23, 2016 at 1:06 PM, Bernd Eckenfels wrote: > Am Fri, 23 Dec 2016 12:54:14 -0800 > schrieb Charles Honton : > > > The > > official release source tarball contains just the sources, not all > > the project files. Building the artifact from

Re: [ALL] Changing the commons process

Am Fri, 23 Dec 2016 12:54:14 -0800 schrieb Charles Honton : > 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

[ALL] Changing the commons process

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

Re: [parent] Publishing src Distributions to Nexus?

> On Dec 23, 2016, at 3:41 AM, Stefan Bodewig wrote: > > Hi all > > the RC1 vote for Parent 42 failed because it no longer pulishes the > source tarballs/zips to Nexus. > > The change was > which has > obviously been a

Re: [parent] Publishing src Distributions to Nexus?

On 23 December 2016 at 12:35, Gilles wrote: > On Fri, 23 Dec 2016 12:41:29 +0100, Stefan Bodewig wrote: >> >> Hi all >> >> the RC1 vote for Parent 42 failed because it no longer pulishes the >> source tarballs/zips to Nexus. > > > It was also requested that the "bin"

Re: [parent] Publishing src Distributions to Nexus?

On Fri, 23 Dec 2016 12:41:29 +0100, Stefan Bodewig wrote: Hi all the RC1 vote for Parent 42 failed because it no longer pulishes the source tarballs/zips to Nexus. It was also requested that the "bin" tar and zip files (and associated checksum and hash) be manually removed from Nexus. A

[parent] Publishing src Distributions to Nexus?

Hi all the RC1 vote for Parent 42 failed because it no longer pulishes the source tarballs/zips to Nexus. The change was which has obviously been a conscious decision. A decision that I personally agree with, I've manually removed the source