[ALL] Dist layout change to per version directories

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

[ALL] Dist layout change to per version directories

sebb-2-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Dist layout change to per version directories

garydgregory
I am OK with anything that makes releasing easier.

Gary

On Fri, Apr 15, 2016 at 4:02 PM, sebb <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Dist layout change to per version directories

James Carman
That definitely seems easier. +1. Would that mess up any sort of sync jobs
(maven and stuff)?
On Fri, Apr 15, 2016 at 7:26 PM Gary Gregory <[hidden email]> wrote:

> I am OK with anything that makes releasing easier.
>
> Gary
>
> On Fri, Apr 15, 2016 at 4:02 PM, sebb <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> E-Mail: [hidden email] | [hidden email]
> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Dist layout change to per version directories

sebb-2-2
On 16 April 2016 at 01:00, James Carman <[hidden email]> 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 <[hidden email]> wrote:
>
>> I am OK with anything that makes releasing easier.
>>
>> Gary
>>
>> On Fri, Apr 15, 2016 at 4:02 PM, sebb <[hidden email]> 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: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>> >
>>
>>
>> --
>> E-Mail: [hidden email] | [hidden email]
>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Dist layout change to per version directories

sebb-2-2
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 <[hidden email]> wrote:

> On 16 April 2016 at 01:00, James Carman <[hidden email]> 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 <[hidden email]> wrote:
>>
>>> I am OK with anything that makes releasing easier.
>>>
>>> Gary
>>>
>>> On Fri, Apr 15, 2016 at 4:02 PM, sebb <[hidden email]> 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: [hidden email]
>>> > For additional commands, e-mail: [hidden email]
>>> >
>>> >
>>>
>>>
>>> --
>>> E-Mail: [hidden email] | [hidden email]
>>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Dist layout change to per version directories

Emmanuel Bourg-3
In reply to this post by sebb-2-2
Le 16/04/2016 01:02, sebb a écrit :

> 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].*

It we change the layout I'd prefer using the component name instead of
the artifactId as the base of the directory name:

  lang/commons-lang-2.6/commons-lang-2.6-[bin|src].*
  lang/commons-lang-3.4/commons-lang3-3.4-[bin|src].*

Emmanuel Bourg


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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Dist layout change to per version directories

Stian Soiland-Reyes
In reply to this post by sebb-2-2
+1 for the change for future releases. Being able to do svn mv (or rm) on a
single folder simplifies releasing and reduces chance of errors.

Is the -src and -bin endings already used across all of Commons? That would
be a bit more important without source/ and binaries/

(Do some have download artifacts beyond bin and src?)

I think it is important to mention this URL pattern change in release notes
for downstream distributors, e.g. Debian recipies that download
https://archive.apache.org/commons/foo/source/foo-${version}-src.tar.gz

(They have to use archive as older versions disappear from official mirrors)
On 16 Apr 2016 00:02, "sebb" <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Dist layout change to per version directories

Gilles Sadowski
On Mon, 18 Apr 2016 09:12:16 +0100, Stian Soiland-Reyes wrote:
> +1 for the change for future releases. Being able to do svn mv (or
> rm) on a
> single folder simplifies releasing and reduces chance of errors.

I think that your remark below calls for making the changes for all
components right now.
Otherwise scripts will require to behave differently for different
components, and force maintainers modify them each time a component
adopts the new scheme.

The new directories should be created also for existing releases, so
that maintainers will have to change their scripts only once.

Gilles

> Is the -src and -bin endings already used across all of Commons? That
> would
> be a bit more important without source/ and binaries/
>
> (Do some have download artifacts beyond bin and src?)
>
> I think it is important to mention this URL pattern change in release
> notes
> for downstream distributors, e.g. Debian recipies that download
>
> https://archive.apache.org/commons/foo/source/foo-${version}-src.tar.gz
>
> (They have to use archive as older versions disappear from official
> mirrors)
> On 16 Apr 2016 00:02, "sebb" <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Dist layout change to per version directories

Gilles Sadowski
In reply to this post by Emmanuel Bourg-3
On Mon, 18 Apr 2016 08:53:10 +0200, Emmanuel Bourg wrote:

> Le 16/04/2016 01:02, sebb a écrit :
>
>> 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].*
>
> It we change the layout I'd prefer using the component name instead
> of
> the artifactId as the base of the directory name:
>
>   lang/commons-lang-2.6/commons-lang-2.6-[bin|src].*
>   lang/commons-lang-3.4/commons-lang3-3.4-[bin|src].*
          ^^^^^^^^^^^^
IIRC, I was once corrected that this is not the component's name (which
in this case would be "Apache Commons Lang").

Moreover, it might be confusing to have different "basenames" (one
for locating this directory and another for locating the artefacts
through a system such as maven).

Gilles

>
> Emmanuel Bourg
>
>


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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Dist layout change to per version directories

Stian Soiland-Reyes
In reply to this post by Gilles Sadowski
Changing download links for all existing releases (without a new release)
sounds worse than having slightly inconsistent paths for a while.

Moving the existing releases would also cause duplicates on
archive.apache.org (unless we ask INFRA to reorganise this as well, which
would break even permalink downloads)

However it is also likely that some of the many stable commons components
won't get a new release in a while (many releases are from 2013 or 2014),
so such inconsistency could take long to get rid off.

Would the mirror folks kill us if we do an svn symlinks from the existing
releases to the new layout and let the existing stay until they have been
replaced by newer versions?  (This would add another 550 MB for mirrors
that don't understand symlinks)
On 18 Apr 2016 09:55, "Gilles" <[hidden email]> wrote:

> On Mon, 18 Apr 2016 09:12:16 +0100, Stian Soiland-Reyes wrote:
>
>> +1 for the change for future releases. Being able to do svn mv (or rm) on
>> a
>> single folder simplifies releasing and reduces chance of errors.
>>
>
> I think that your remark below calls for making the changes for all
> components right now.
> Otherwise scripts will require to behave differently for different
> components, and force maintainers modify them each time a component
> adopts the new scheme.
>
> The new directories should be created also for existing releases, so
> that maintainers will have to change their scripts only once.
>
> Gilles
>
> Is the -src and -bin endings already used across all of Commons? That would
>> be a bit more important without source/ and binaries/
>>
>> (Do some have download artifacts beyond bin and src?)
>>
>> I think it is important to mention this URL pattern change in release
>> notes
>> for downstream distributors, e.g. Debian recipies that download
>>
>> https://archive.apache.org/commons/foo/source/foo-${version}-src.tar.gz
>>
>> (They have to use archive as older versions disappear from official
>> mirrors)
>> On 16 Apr 2016 00:02, "sebb" <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Dist layout change to per version directories

Emmanuel Bourg-3
In reply to this post by Gilles Sadowski
Le 18/04/2016 10:48, Gilles a écrit :

> IIRC, I was once corrected that this is not the component's name (which
> in this case would be "Apache Commons Lang").

That's consistent with the site URL though:

  http://commons.apache.org/proper/commons-lang/

An alternative would be to use the version only:

  lang/2.6/commons-lang-2.6-[bin|src].*
  lang/3.4/commons-lang3-3.4-[bin|src].*

Emmanuel Bourg


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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Dist layout change to per version directories

Gilles Sadowski
In reply to this post by Stian Soiland-Reyes
On Mon, 18 Apr 2016 10:22:53 +0100, Stian Soiland-Reyes wrote:
> Changing download links for all existing releases (without a new
> release)
> sounds worse than having slightly inconsistent paths for a while.

I did not suggest to _delete_ anything.
Just that current archives should be accessible through both old and
new scripts. The latter not having to deal with the old layout.

Gilles

> Moving the existing releases would also cause duplicates on
> archive.apache.org (unless we ask INFRA to reorganise this as well,
> which
> would break even permalink downloads)
>
> However it is also likely that some of the many stable commons
> components
> won't get a new release in a while (many releases are from 2013 or
> 2014),
> so such inconsistency could take long to get rid off.
>
> Would the mirror folks kill us if we do an svn symlinks from the
> existing
> releases to the new layout and let the existing stay until they have
> been
> replaced by newer versions?  (This would add another 550 MB for
> mirrors
> that don't understand symlinks)
> On 18 Apr 2016 09:55, "Gilles" <[hidden email]> wrote:
>
>> On Mon, 18 Apr 2016 09:12:16 +0100, Stian Soiland-Reyes wrote:
>>
>>> +1 for the change for future releases. Being able to do svn mv (or
>>> rm) on
>>> a
>>> single folder simplifies releasing and reduces chance of errors.
>>>
>>
>> I think that your remark below calls for making the changes for all
>> components right now.
>> Otherwise scripts will require to behave differently for different
>> components, and force maintainers modify them each time a component
>> adopts the new scheme.
>>
>> The new directories should be created also for existing releases, so
>> that maintainers will have to change their scripts only once.
>>
>> Gilles
>>
>> Is the -src and -bin endings already used across all of Commons?
>> That would
>>> be a bit more important without source/ and binaries/
>>>
>>> (Do some have download artifacts beyond bin and src?)
>>>
>>> I think it is important to mention this URL pattern change in
>>> release
>>> notes
>>> for downstream distributors, e.g. Debian recipies that download
>>>
>>>
>>> https://archive.apache.org/commons/foo/source/foo-${version}-src.tar.gz
>>>
>>> (They have to use archive as older versions disappear from official
>>> mirrors)
>>> On 16 Apr 2016 00:02, "sebb" <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>


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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Dist layout change to per version directories

Gilles Sadowski
In reply to this post by Emmanuel Bourg-3
On Mon, 18 Apr 2016 11:18:49 +0200, Emmanuel Bourg wrote:
> Le 18/04/2016 10:48, Gilles a écrit :
>
>> IIRC, I was once corrected that this is not the component's name
>> (which
>> in this case would be "Apache Commons Lang").
>
> That's consistent with the site URL though:
>
>   http://commons.apache.org/proper/commons-lang/

I know; and from a purely aesthetics ;-) POV, I also prefer a reference
to the "component" rather than the "id" which is a concatenation (of
a name and a version) that exists for practical reasons.

But isn't the change also for a practical reason, namely to avoid
confusing artefacts?

Hence I thought that the focus should be on the "id", contrary to e.g.
the web site whose primary focus is to document the "component".

>
> An alternative would be to use the version only:
>
>   lang/2.6/commons-lang-2.6-[bin|src].*
>   lang/3.4/commons-lang3-3.4-[bin|src].*

Perhaps.  It really depends on the issues which the change is trying
to solve; the new scheme should be a solution that does not create
new confusions.

Gilles

> Emmanuel Bourg
>
>


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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Dist layout change to per version directories

Stian Soiland-Reyes
In reply to this post by Gilles Sadowski
Ah - as long as the INFRA and Mirror guys are OK with the potentially
extra 500 MB then that sounds good!

I've raised
https://issues.apache.org/jira/browse/INFRA-11702
to enquire how we should best do it.



BTW - the -bin and -src suffixes are quite consistent across the
boards. These are the only files that don't match that pattern:


stain@biggie:~/Downloads/912/mirrors.ukfast.co.uk/sites/ftp.apache.org$
find . -type f | grep -v txt  | grep -v -- -src.tar.gz | grep -v --
-src.zip | grep -v -- -bin.zip | grep -v -- -bin.tar.gz

./commons/proxy/binaries/commons-proxy-1.0.tar.gz
./commons/proxy/binaries/commons-proxy-1.0.zip
./commons/primitives/binaries/commons-primitives-1.0.tar.gz
./commons/primitives/binaries/commons-primitives-1.0.zip
./commons/jexl/binaries/commons-jexl-1.1.tar.gz
./commons/jexl/binaries/commons-jexl-1.1.zip
./commons/attributes/binaries/commons-attributes-2.2.tar.gz
./commons/attributes/binaries/commons-attributes-2.2.zip
./commons/bsf/binaries/bsf-bin-2.4.0.tar.gz
./commons/bsf/binaries/bsf-bin-2.4.0.zip
./commons/bsf/source/bsf-src-2.4.0.tar.gz
./commons/bsf/source/bsf-src-2.4.0.zip
./commons/el/binaries/commons-el-1.0.zip
./commons/el/binaries/commons-el-1.0.tar.gz
./commons/vfs/binaries/commons-vfs-2.0.tar.gz
./commons/vfs/binaries/commons-vfs-2.0.zip
./commons/betwixt/binaries/commons-betwixt-0.8.zip
./commons/betwixt/binaries/commons-betwixt-0.8.tar.gz
./commons/bcel/binaries/bcel-5.2.tar.gz
./commons/bcel/binaries/bcel-5.2.zip
./commons/daemon/binaries/commons-daemon-1.0.15.jar
./commons/daemon/binaries/windows/commons-daemon-1.0.15-bin-windows.zip
./commons/daemon/binaries/windows/commons-daemon-1.0.15-bin-windows-signed.zip
./commons/jelly/binaries/commons-jelly-1.0.zip
./commons/jelly/binaries/commons-jelly-1.0.tar.gz
./commons/launcher/binaries/commons-launcher-1.1.tar.gz
./commons/launcher/binaries/commons-launcher-1.1-example.tar.gz
./commons/launcher/binaries/commons-launcher-1.1.zip
./commons/launcher/binaries/commons-launcher-1.1-example.zip
./commons/transaction/binaries/commons-transaction-1.2.zip
./commons/transaction/binaries/commons-transaction-1.2.tar.gz
./commons/modeler/binaries/commons-modeler-2.0.1.tar.gz
./commons/modeler/binaries/commons-modeler-2.0.1.zip
./commons/sanselan/binaries/apache-sanselan-incubating-0.97-bin.tar.bz2
./commons/sanselan/source/apache-sanselan-incubating-0.97-src.tar.bz2
./commons/math/binaries/commons-math-2.2.tar.gz
./commons/math/binaries/commons-math-2.2.zip
./commons/net/binaries/commons-net-1.4.1.tar.gz
./commons/net/binaries/commons-net-1.4.1.zip
./commons/jcs/binaries/jcs-1.3.tar.gz
./commons/jcs/binaries/jcs-1.3.zip

Most of those are binaries that simply lack "-bin" (oh no!) - so they
could just be changed to the new pattern manually within the new
layout.



On 18 April 2016 at 10:28, Gilles <[hidden email]> wrote:

> On Mon, 18 Apr 2016 10:22:53 +0100, Stian Soiland-Reyes wrote:
>>
>> Changing download links for all existing releases (without a new release)
>> sounds worse than having slightly inconsistent paths for a while.
>
>
> I did not suggest to _delete_ anything.
> Just that current archives should be accessible through both old and
> new scripts. The latter not having to deal with the old layout.
>
> Gilles
>
>
>> Moving the existing releases would also cause duplicates on
>> archive.apache.org (unless we ask INFRA to reorganise this as well, which
>> would break even permalink downloads)
>>
>> However it is also likely that some of the many stable commons components
>> won't get a new release in a while (many releases are from 2013 or 2014),
>> so such inconsistency could take long to get rid off.
>>
>> Would the mirror folks kill us if we do an svn symlinks from the existing
>> releases to the new layout and let the existing stay until they have been
>> replaced by newer versions?  (This would add another 550 MB for mirrors
>> that don't understand symlinks)
>> On 18 Apr 2016 09:55, "Gilles" <[hidden email]> wrote:
>>
>>> On Mon, 18 Apr 2016 09:12:16 +0100, Stian Soiland-Reyes wrote:
>>>
>>>> +1 for the change for future releases. Being able to do svn mv (or rm)
>>>> on
>>>> a
>>>> single folder simplifies releasing and reduces chance of errors.
>>>>
>>>
>>> I think that your remark below calls for making the changes for all
>>> components right now.
>>> Otherwise scripts will require to behave differently for different
>>> components, and force maintainers modify them each time a component
>>> adopts the new scheme.
>>>
>>> The new directories should be created also for existing releases, so
>>> that maintainers will have to change their scripts only once.
>>>
>>> Gilles
>>>
>>> Is the -src and -bin endings already used across all of Commons? That
>>> would
>>>>
>>>> be a bit more important without source/ and binaries/
>>>>
>>>> (Do some have download artifacts beyond bin and src?)
>>>>
>>>> I think it is important to mention this URL pattern change in release
>>>> notes
>>>> for downstream distributors, e.g. Debian recipies that download
>>>>
>>>>
>>>> https://archive.apache.org/commons/foo/source/foo-${version}-src.tar.gz
>>>>
>>>> (They have to use archive as older versions disappear from official
>>>> mirrors)
>>>> On 16 Apr 2016 00:02, "sebb" <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>



--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/0000-0001-9842-9718

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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Dist layout change to per version directories

Stian Soiland-Reyes
In reply to this post by Gilles Sadowski
We might also want to include the "apache-" file prefix for trademark
reasons - as advocated to all incubator projects.

e.g.

/commons/lang/3.4/apache-commons-lang3-3.4-src.tar.gz




On 18 April 2016 at 10:40, Gilles <[hidden email]> wrote:

> On Mon, 18 Apr 2016 11:18:49 +0200, Emmanuel Bourg wrote:
>>
>> Le 18/04/2016 10:48, Gilles a écrit :
>>
>>> IIRC, I was once corrected that this is not the component's name (which
>>> in this case would be "Apache Commons Lang").
>>
>>
>> That's consistent with the site URL though:
>>
>>   http://commons.apache.org/proper/commons-lang/
>
>
> I know; and from a purely aesthetics ;-) POV, I also prefer a reference
> to the "component" rather than the "id" which is a concatenation (of
> a name and a version) that exists for practical reasons.
>
> But isn't the change also for a practical reason, namely to avoid
> confusing artefacts?
>
> Hence I thought that the focus should be on the "id", contrary to e.g.
> the web site whose primary focus is to document the "component".
>
>>
>> An alternative would be to use the version only:
>>
>>   lang/2.6/commons-lang-2.6-[bin|src].*
>>   lang/3.4/commons-lang3-3.4-[bin|src].*
>
>
> Perhaps.  It really depends on the issues which the change is trying
> to solve; the new scheme should be a solution that does not create
> new confusions.
>
> Gilles
>
>
>> Emmanuel Bourg
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>



--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/0000-0001-9842-9718

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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Dist layout change to per version directories

Gilles Sadowski
On Mon, 18 Apr 2016 10:45:28 +0100, Stian Soiland-Reyes wrote:
> We might also want to include the "apache-" file prefix for trademark
> reasons - as advocated to all incubator projects.
>
> e.g.
>
> /commons/lang/3.4/apache-commons-lang3-3.4-src.tar.gz
>

That certainly makes a lot of sense, also to avoid potential name
clashes.

Can it be added automatically to the artefacts, i.e. without requiring
that the "id" be changed?

Gilles

> On 18 April 2016 at 10:40, Gilles <[hidden email]>
> wrote:
>> On Mon, 18 Apr 2016 11:18:49 +0200, Emmanuel Bourg wrote:
>>>
>>> Le 18/04/2016 10:48, Gilles a écrit :
>>>
>>>> IIRC, I was once corrected that this is not the component's name
>>>> (which
>>>> in this case would be "Apache Commons Lang").
>>>
>>>
>>> That's consistent with the site URL though:
>>>
>>>   http://commons.apache.org/proper/commons-lang/
>>
>>
>> I know; and from a purely aesthetics ;-) POV, I also prefer a
>> reference
>> to the "component" rather than the "id" which is a concatenation (of
>> a name and a version) that exists for practical reasons.
>>
>> But isn't the change also for a practical reason, namely to avoid
>> confusing artefacts?
>>
>> Hence I thought that the focus should be on the "id", contrary to
>> e.g.
>> the web site whose primary focus is to document the "component".
>>
>>>
>>> An alternative would be to use the version only:
>>>
>>>   lang/2.6/commons-lang-2.6-[bin|src].*
>>>   lang/3.4/commons-lang3-3.4-[bin|src].*
>>
>>
>> Perhaps.  It really depends on the issues which the change is trying
>> to solve; the new scheme should be a solution that does not create
>> new confusions.
>>
>> Gilles
>>
>>
>>> Emmanuel Bourg
>>>


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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Dist layout change to per version directories

sebb-2-2
On 18 April 2016 at 10:59, Gilles <[hidden email]> wrote:

> On Mon, 18 Apr 2016 10:45:28 +0100, Stian Soiland-Reyes wrote:
>>
>> We might also want to include the "apache-" file prefix for trademark
>> reasons - as advocated to all incubator projects.
>>
>> e.g.
>>
>> /commons/lang/3.4/apache-commons-lang3-3.4-src.tar.gz
>>
>
> That certainly makes a lot of sense, also to avoid potential name clashes.
>
> Can it be added automatically to the artefacts, i.e. without requiring
> that the "id" be changed?

That's a separate issue, please start a new e-mail thread.

> Gilles
>
>
>> On 18 April 2016 at 10:40, Gilles <[hidden email]> wrote:
>>>
>>> On Mon, 18 Apr 2016 11:18:49 +0200, Emmanuel Bourg wrote:
>>>>
>>>>
>>>> Le 18/04/2016 10:48, Gilles a écrit :
>>>>
>>>>> IIRC, I was once corrected that this is not the component's name (which
>>>>> in this case would be "Apache Commons Lang").
>>>>
>>>>
>>>>
>>>> That's consistent with the site URL though:
>>>>
>>>>   http://commons.apache.org/proper/commons-lang/
>>>
>>>
>>>
>>> I know; and from a purely aesthetics ;-) POV, I also prefer a reference
>>> to the "component" rather than the "id" which is a concatenation (of
>>> a name and a version) that exists for practical reasons.
>>>
>>> But isn't the change also for a practical reason, namely to avoid
>>> confusing artefacts?
>>>
>>> Hence I thought that the focus should be on the "id", contrary to e.g.
>>> the web site whose primary focus is to document the "component".
>>>
>>>>
>>>> An alternative would be to use the version only:
>>>>
>>>>   lang/2.6/commons-lang-2.6-[bin|src].*
>>>>   lang/3.4/commons-lang3-3.4-[bin|src].*
>>>
>>>
>>>
>>> Perhaps.  It really depends on the issues which the change is trying
>>> to solve; the new scheme should be a solution that does not create
>>> new confusions.
>>>
>>> Gilles
>>>
>>>
>>>> Emmanuel Bourg
>>>>
>
>
> ---------------------------------------------------------------------
> 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]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Dist layout change to per version directories

sebb-2-2
In reply to this post by Stian Soiland-Reyes
Adding -bin to artifact names is a separate issue, please start a new thread.

On 18 April 2016 at 10:43, Stian Soiland-Reyes <[hidden email]> wrote:

> Ah - as long as the INFRA and Mirror guys are OK with the potentially
> extra 500 MB then that sounds good!
>
> I've raised
> https://issues.apache.org/jira/browse/INFRA-11702
> to enquire how we should best do it.
>
>
>
> BTW - the -bin and -src suffixes are quite consistent across the
> boards. These are the only files that don't match that pattern:
>
>
> stain@biggie:~/Downloads/912/mirrors.ukfast.co.uk/sites/ftp.apache.org$
> find . -type f | grep -v txt  | grep -v -- -src.tar.gz | grep -v --
> -src.zip | grep -v -- -bin.zip | grep -v -- -bin.tar.gz
>
> ./commons/proxy/binaries/commons-proxy-1.0.tar.gz
> ./commons/proxy/binaries/commons-proxy-1.0.zip
> ./commons/primitives/binaries/commons-primitives-1.0.tar.gz
> ./commons/primitives/binaries/commons-primitives-1.0.zip
> ./commons/jexl/binaries/commons-jexl-1.1.tar.gz
> ./commons/jexl/binaries/commons-jexl-1.1.zip
> ./commons/attributes/binaries/commons-attributes-2.2.tar.gz
> ./commons/attributes/binaries/commons-attributes-2.2.zip
> ./commons/bsf/binaries/bsf-bin-2.4.0.tar.gz
> ./commons/bsf/binaries/bsf-bin-2.4.0.zip
> ./commons/bsf/source/bsf-src-2.4.0.tar.gz
> ./commons/bsf/source/bsf-src-2.4.0.zip
> ./commons/el/binaries/commons-el-1.0.zip
> ./commons/el/binaries/commons-el-1.0.tar.gz
> ./commons/vfs/binaries/commons-vfs-2.0.tar.gz
> ./commons/vfs/binaries/commons-vfs-2.0.zip
> ./commons/betwixt/binaries/commons-betwixt-0.8.zip
> ./commons/betwixt/binaries/commons-betwixt-0.8.tar.gz
> ./commons/bcel/binaries/bcel-5.2.tar.gz
> ./commons/bcel/binaries/bcel-5.2.zip
> ./commons/daemon/binaries/commons-daemon-1.0.15.jar
> ./commons/daemon/binaries/windows/commons-daemon-1.0.15-bin-windows.zip
> ./commons/daemon/binaries/windows/commons-daemon-1.0.15-bin-windows-signed.zip
> ./commons/jelly/binaries/commons-jelly-1.0.zip
> ./commons/jelly/binaries/commons-jelly-1.0.tar.gz
> ./commons/launcher/binaries/commons-launcher-1.1.tar.gz
> ./commons/launcher/binaries/commons-launcher-1.1-example.tar.gz
> ./commons/launcher/binaries/commons-launcher-1.1.zip
> ./commons/launcher/binaries/commons-launcher-1.1-example.zip
> ./commons/transaction/binaries/commons-transaction-1.2.zip
> ./commons/transaction/binaries/commons-transaction-1.2.tar.gz
> ./commons/modeler/binaries/commons-modeler-2.0.1.tar.gz
> ./commons/modeler/binaries/commons-modeler-2.0.1.zip
> ./commons/sanselan/binaries/apache-sanselan-incubating-0.97-bin.tar.bz2
> ./commons/sanselan/source/apache-sanselan-incubating-0.97-src.tar.bz2
> ./commons/math/binaries/commons-math-2.2.tar.gz
> ./commons/math/binaries/commons-math-2.2.zip
> ./commons/net/binaries/commons-net-1.4.1.tar.gz
> ./commons/net/binaries/commons-net-1.4.1.zip
> ./commons/jcs/binaries/jcs-1.3.tar.gz
> ./commons/jcs/binaries/jcs-1.3.zip
>
> Most of those are binaries that simply lack "-bin" (oh no!) - so they
> could just be changed to the new pattern manually within the new
> layout.
>
>
>
> On 18 April 2016 at 10:28, Gilles <[hidden email]> wrote:
>> On Mon, 18 Apr 2016 10:22:53 +0100, Stian Soiland-Reyes wrote:
>>>
>>> Changing download links for all existing releases (without a new release)
>>> sounds worse than having slightly inconsistent paths for a while.
>>
>>
>> I did not suggest to _delete_ anything.
>> Just that current archives should be accessible through both old and
>> new scripts. The latter not having to deal with the old layout.
>>
>> Gilles
>>
>>
>>> Moving the existing releases would also cause duplicates on
>>> archive.apache.org (unless we ask INFRA to reorganise this as well, which
>>> would break even permalink downloads)
>>>
>>> However it is also likely that some of the many stable commons components
>>> won't get a new release in a while (many releases are from 2013 or 2014),
>>> so such inconsistency could take long to get rid off.
>>>
>>> Would the mirror folks kill us if we do an svn symlinks from the existing
>>> releases to the new layout and let the existing stay until they have been
>>> replaced by newer versions?  (This would add another 550 MB for mirrors
>>> that don't understand symlinks)
>>> On 18 Apr 2016 09:55, "Gilles" <[hidden email]> wrote:
>>>
>>>> On Mon, 18 Apr 2016 09:12:16 +0100, Stian Soiland-Reyes wrote:
>>>>
>>>>> +1 for the change for future releases. Being able to do svn mv (or rm)
>>>>> on
>>>>> a
>>>>> single folder simplifies releasing and reduces chance of errors.
>>>>>
>>>>
>>>> I think that your remark below calls for making the changes for all
>>>> components right now.
>>>> Otherwise scripts will require to behave differently for different
>>>> components, and force maintainers modify them each time a component
>>>> adopts the new scheme.
>>>>
>>>> The new directories should be created also for existing releases, so
>>>> that maintainers will have to change their scripts only once.
>>>>
>>>> Gilles
>>>>
>>>> Is the -src and -bin endings already used across all of Commons? That
>>>> would
>>>>>
>>>>> be a bit more important without source/ and binaries/
>>>>>
>>>>> (Do some have download artifacts beyond bin and src?)
>>>>>
>>>>> I think it is important to mention this URL pattern change in release
>>>>> notes
>>>>> for downstream distributors, e.g. Debian recipies that download
>>>>>
>>>>>
>>>>> https://archive.apache.org/commons/foo/source/foo-${version}-src.tar.gz
>>>>>
>>>>> (They have to use archive as older versions disappear from official
>>>>> mirrors)
>>>>> On 16 Apr 2016 00:02, "sebb" <[hidden email]> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons RDF (incubating)
> http://orcid.org/0000-0001-9842-9718
>
> ---------------------------------------------------------------------
> 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]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Dist layout change to per version directories

sebb-2-2
In reply to this post by Emmanuel Bourg-3
On 18 April 2016 at 07:53, Emmanuel Bourg <[hidden email]> wrote:

> Le 16/04/2016 01:02, sebb a écrit :
>
>> 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].*
>
> It we change the layout I'd prefer using the component name instead of
> the artifactId as the base of the directory name:
>
>   lang/commons-lang-2.6/commons-lang-2.6-[bin|src].*
>   lang/commons-lang-3.4/commons-lang3-3.4-[bin|src].*

Why is that?

> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> 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]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Dist layout change to per version directories

Emmanuel Bourg-3
Le 18/04/2016 12:56, sebb a écrit :

> Why is that?

Because there is no reason to use the Maven artifactId here, the
distribution directory isn't a Maven repository. That's the same
reasoning for the -bin and -src files, commons-lang3-3.4 can be mistaken
for commons-lang 3.3.4.

Emmanuel Bourg


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

12