Note: the facility has been implemented in version 1.6 of the build plugin. This is currently under lazy vote approval; assume no issues will be available in a few days time.
I intend to use it for the Net and Validator releases. On 16 April 2016 at 09:36, sebb <seb...@gmail.com> wrote: > On 16 April 2016 at 01:00, James Carman <ja...@carmanconsulting.com> wrote: >> That definitely seems easier. +1. > > Another advantage is that it should make it simpler to automate > creating the dist/dev staging area from Nexus. > The staging area could be created as dist/dev/commons/abc/abc-123-RC4. > There would then be less chance of voting on stale artifacts as each > RC would have its own area. > >> Would that mess up any sort of sync jobs >> (maven and stuff)? > > AFAIK Maven does not know the existing layout, since it varies between > projects. > (The commons build plugin is the only place that does know, and it has > to be specifically told) > > Mirrors will take everything under dist, including dist/commons > > I suppose it's possible some 3rd parties may make assumptions about > the layout, but it's not standard across ASF projects. > >> On Fri, Apr 15, 2016 at 7:26 PM Gary Gregory <garydgreg...@gmail.com> wrote: >> >>> I am OK with anything that makes releasing easier. >>> >>> Gary >>> >>> On Fri, Apr 15, 2016 at 4:02 PM, sebb <seb...@gmail.com> wrote: >>> >>> > The dist layout currently splits archives into source/ and binaries/. >>> > Where there are multiple active versions, these are all in the same >>> > directory. >>> > >>> > IMO this layout is not ideal any more. >>> > >>> > It is harder to tidy up old releases (files have to be individually >>> > deleted) >>> > It is harder to move files from dist/dev to dist/release >>> > >>> > Are there any disadvantages to allowing the layout to change? >>> > >>> > Unless there are objections, I propose to update the commons build >>> > plugin to support download pages using version ids, e.g. instead of >>> > the present layout: >>> > >>> > lang/source/commons-lang-2.6-src.* >>> > lang/source/commons-lang3-3.4-src.* >>> > lang/binaries/commons-lang-2.6-bin.* >>> > lang/binaries/commons-lang3-3.4-bin.* >>> > >>> > It would look like: >>> > >>> > lang/commons-lang-2.6/commons-lang-2.6-[bin|src].* >>> > lang/commons-lang3-3.4/commons-lang3-3.4-[bin|src].* >>> > >>> > >>> > Note: I don't think we should move the existing releases >>> > >>> > The intention is to allow new releases to optionally migrate to the new >>> > layout. >>> > This would be done on the basis of a new property, e.g. >>> > commons.release.layout=version >>> > If the property is defined, then the new layout is used; if not, then >>> > the current source/binaries layout is used. >>> > >>> > --------------------------------------------------------------------- >>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> > For additional commands, e-mail: dev-h...@commons.apache.org >>> > >>> > >>> >>> >>> -- >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>> Java Persistence with Hibernate, Second Edition >>> <http://www.manning.com/bauer3/> >>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>> Spring Batch in Action <http://www.manning.com/templier/> >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >>> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
