You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <ga...@gmail.com> on 2013/12/13 03:50:33 UTC
[all] simplifying releases: dist vs. maven repo
Hi All:
We talk on and off as to how painful it is to release components.
One of these pains is that we distribute to multiple places: An Apache
"dist" folder and the Apache Maven repository.
Clearly, Maven is here to stay.
So why not deploy the -src and -bin files to Maven and forget about dist. A
URL is a URL, what do users care is the URL points deep into "dist" or our
Maven repo. I for one, need the -bin zips for certain Apache projects
(JMeter, ActiveMQ) so my Ant Ivy builds can download and install them.
I know we have some legal requirements to host at least the sources and
that we provide binaries as a "courtesy" but does it matter _where_ the
files are on Apache servers?
Thoughts?
Gary
--
E-Mail: garydgregory@gmail.com | ggregory@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
Re: [all] simplifying releases: dist vs. maven repo
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 13/12/2013 10:58, Bernd Eckenfels a écrit :
> I find it very usefull when the IDE will automatically download javadocs
> and sources for a given dependency so I can browse into. For this to
> work -src and -javadoc have to be in the repo.
I agree, but that's the -sources artifact, not the -src one.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] simplifying releases: dist vs. maven repo
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Am 13.12.2013, 07:29 Uhr, schrieb Emmanuel Bourg <eb...@apache.org>:
> I don't think the -src and -bin files should be in Maven, that's not its
> purpose.
I find it very usefull when the IDE will automatically download javadocs
and sources for a given dependency so I can browse into. For this to work
-src and -javadoc have to be in the repo.
Gruss
Bernd
--
http://www.zusammenkunft.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] simplifying releases: dist vs. maven repo
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 13/12/2013 03:50, Gary Gregory a écrit :
> Thoughts?
I don't think the -src and -bin files should be in Maven, that's not its
purpose.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] simplifying releases: dist vs. maven repo
Posted by Oliver Heger <ol...@oliver-heger.de>.
Am 15.12.2013 22:29, schrieb Phil Steitz:
> On 12/14/13, 12:01 PM, Oliver Heger wrote:
>> Am 14.12.2013 05:20, schrieb Phil Steitz:
>>> On 12/13/13, 12:34 PM, Gary Gregory wrote:
>>>> On Fri, Dec 13, 2013 at 3:29 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>>
>>>>> On 12/13/13, 11:34 AM, Gary Gregory wrote:
>>>>>> On Fri, Dec 13, 2013 at 12:57 AM, Phil Steitz <ph...@gmail.com>
>>>>> wrote:
>>>>>>> On 12/12/13, 6:50 PM, Gary Gregory wrote:
>>>>>>>> Hi All:
>>>>>>>>
>>>>>>>> We talk on and off as to how painful it is to release components.
>>>>>>>>
>>>>>>>> One of these pains is that we distribute to multiple places: An Apache
>>>>>>>> "dist" folder and the Apache Maven repository.
>>>>>>>>
>>>>>>>> Clearly, Maven is here to stay.
>>>>>>>>
>>>>>>>> So why not deploy the -src and -bin files to Maven and forget about
>>>>>>> dist. A
>>>>>>>> URL is a URL, what do users care is the URL points deep into "dist" or
>>>>>>> our
>>>>>>>> Maven repo. I for one, need the -bin zips for certain Apache projects
>>>>>>>> (JMeter, ActiveMQ) so my Ant Ivy builds can download and install them.
>>>>>>>>
>>>>>>>> I know we have some legal requirements to host at least the sources and
>>>>>>>> that we provide binaries as a "courtesy" but does it matter _where_ the
>>>>>>>> files are on Apache servers?
>>>>>>> The releases need to be mirrored. That's what dist is for.
>>>>>>>
>>>>>> How is this not the same thing that happens with the Maven repo, which is
>>>>>> mirrored all over as well? Please educate/correct me.
>>>>> See Mark's comments. We need to either say we are not directly
>>>>> providing artifacts to users (not acceptable, IMO),
>>>> We are, for example:
>>>> https://repository.apache.org/content/repositories/releases/
>>> We should not be pointing users at that URL for download, because it
>>> is not a mirror reference (Mark or some infra@-knowledgeable person
>>> can correct me if I am wrong here). The mirrors exist in part to
>>> prevent ASF servers getting hammered by end-users trying to download
>>> artifacts. Pointing end-users to repo.a.o is pointing them directly
>>> at ASF infra, which is a no-no (because it does not take advantage
>>> of the load-distribution advantage of the mirroring system). As I
>>> said above, if we want to go this way, we will have to point them at
>>> maven central, which runs afoul of the requirement that Sebb
>>> references.
>>>>
>>>>> or direct users
>>>>> to mirrors.
>>>> Which could point to Maven Central and the like.
>>>>
>>>>
>>>> The way dist and the various download cgis work is that
>>>>> users are directed to download the artifacts from mirrors near them,
>>>>> not directly from ASF servers. I guess we could in theory direct
>>>>> them to maven central, but that makes me a little twitchy as we
>>>>> don't really control or monitor the process of mirroring there.
>>>>>
>>>> As noted above, we control
>>>> https://repository.apache.org/content/repositories/releases/
>>> Right, but we can't point end-users there, per comments above.
>>>
>>> Phil
>>>> Gary
>>>>
>>>>
>>>>> So if we are going to distribute directly, we should continue to do
>>>>> it from dist. Mark also makes a good point about archives.
>>>>>
>>>> https://repository.apache.org/content/repositories/releases/ behaves like
>>>> an archive since it keeps old versions.
>>>>
>>>> Gary
>>>>
>>>>
>>>>> Phil
>>>>>> Thank you,
>>>>>> Gary
>>>>>>
>>>>>>
>>>>>>> Phil
>>>>>>>> Thoughts?
>> Moving artifacts from the dist/dev location to the release location was
>> indeed one of the problematic actions when doing the last [beanutils]
>> release - a whole bunch of commands had to be typed in, and for me it
>> did not work in the way it was described.
>>
>> However, I think that this step could easily be scripted in some way. If
>> there was an easy and automated method for dealing with dist, there
>> would not be much point in searching for an alternative.
>
> You are talking about step 1 in [1], right? I am about to cut my
> first release in a while and I will see if I can verify / simplify
> this. Did this not work for you? What exactly failed? Looks like
> it should work to me, though I would probably do the mvs separately
> locally, then verify directory contents and then commit.
Yes, the moves of the distribution artifacts. I followed the svnmucc
approach and entered a command with the following structure
svnmucc -U <baseURL>
mv <srcDir>/<srcFile> <dstDir>/
...
as described on the page. This always failed with the error message
"<dstDir> already exists". I could only get it to work by changing the
command structure to
mv <srcDir>/<srcFile> <dstDir>/<srcFile>
i.e. the file name had to be repeated. This was indeed strange, I also
would have expected the original command to work. Nevertheless, it
should not be a major problem to write a small script which generates
exactly the correct command based on some file naming conventions.
Oliver
>
> Phil
>
> [1] http://commons.apache.org/releases/release.html
>>
>> Oliver
>>
>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] simplifying releases: dist vs. maven repo
Posted by Phil Steitz <ph...@gmail.com>.
On 12/14/13, 12:01 PM, Oliver Heger wrote:
> Am 14.12.2013 05:20, schrieb Phil Steitz:
>> On 12/13/13, 12:34 PM, Gary Gregory wrote:
>>> On Fri, Dec 13, 2013 at 3:29 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>
>>>> On 12/13/13, 11:34 AM, Gary Gregory wrote:
>>>>> On Fri, Dec 13, 2013 at 12:57 AM, Phil Steitz <ph...@gmail.com>
>>>> wrote:
>>>>>> On 12/12/13, 6:50 PM, Gary Gregory wrote:
>>>>>>> Hi All:
>>>>>>>
>>>>>>> We talk on and off as to how painful it is to release components.
>>>>>>>
>>>>>>> One of these pains is that we distribute to multiple places: An Apache
>>>>>>> "dist" folder and the Apache Maven repository.
>>>>>>>
>>>>>>> Clearly, Maven is here to stay.
>>>>>>>
>>>>>>> So why not deploy the -src and -bin files to Maven and forget about
>>>>>> dist. A
>>>>>>> URL is a URL, what do users care is the URL points deep into "dist" or
>>>>>> our
>>>>>>> Maven repo. I for one, need the -bin zips for certain Apache projects
>>>>>>> (JMeter, ActiveMQ) so my Ant Ivy builds can download and install them.
>>>>>>>
>>>>>>> I know we have some legal requirements to host at least the sources and
>>>>>>> that we provide binaries as a "courtesy" but does it matter _where_ the
>>>>>>> files are on Apache servers?
>>>>>> The releases need to be mirrored. That's what dist is for.
>>>>>>
>>>>> How is this not the same thing that happens with the Maven repo, which is
>>>>> mirrored all over as well? Please educate/correct me.
>>>> See Mark's comments. We need to either say we are not directly
>>>> providing artifacts to users (not acceptable, IMO),
>>> We are, for example:
>>> https://repository.apache.org/content/repositories/releases/
>> We should not be pointing users at that URL for download, because it
>> is not a mirror reference (Mark or some infra@-knowledgeable person
>> can correct me if I am wrong here). The mirrors exist in part to
>> prevent ASF servers getting hammered by end-users trying to download
>> artifacts. Pointing end-users to repo.a.o is pointing them directly
>> at ASF infra, which is a no-no (because it does not take advantage
>> of the load-distribution advantage of the mirroring system). As I
>> said above, if we want to go this way, we will have to point them at
>> maven central, which runs afoul of the requirement that Sebb
>> references.
>>>
>>>> or direct users
>>>> to mirrors.
>>> Which could point to Maven Central and the like.
>>>
>>>
>>> The way dist and the various download cgis work is that
>>>> users are directed to download the artifacts from mirrors near them,
>>>> not directly from ASF servers. I guess we could in theory direct
>>>> them to maven central, but that makes me a little twitchy as we
>>>> don't really control or monitor the process of mirroring there.
>>>>
>>> As noted above, we control
>>> https://repository.apache.org/content/repositories/releases/
>> Right, but we can't point end-users there, per comments above.
>>
>> Phil
>>> Gary
>>>
>>>
>>>> So if we are going to distribute directly, we should continue to do
>>>> it from dist. Mark also makes a good point about archives.
>>>>
>>> https://repository.apache.org/content/repositories/releases/ behaves like
>>> an archive since it keeps old versions.
>>>
>>> Gary
>>>
>>>
>>>> Phil
>>>>> Thank you,
>>>>> Gary
>>>>>
>>>>>
>>>>>> Phil
>>>>>>> Thoughts?
> Moving artifacts from the dist/dev location to the release location was
> indeed one of the problematic actions when doing the last [beanutils]
> release - a whole bunch of commands had to be typed in, and for me it
> did not work in the way it was described.
>
> However, I think that this step could easily be scripted in some way. If
> there was an easy and automated method for dealing with dist, there
> would not be much point in searching for an alternative.
You are talking about step 1 in [1], right? I am about to cut my
first release in a while and I will see if I can verify / simplify
this. Did this not work for you? What exactly failed? Looks like
it should work to me, though I would probably do the mvs separately
locally, then verify directory contents and then commit.
Phil
[1] http://commons.apache.org/releases/release.html
>
> Oliver
>
>
>>>>>>> Gary
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] simplifying releases: dist vs. maven repo
Posted by Oliver Heger <ol...@oliver-heger.de>.
Am 14.12.2013 05:20, schrieb Phil Steitz:
> On 12/13/13, 12:34 PM, Gary Gregory wrote:
>> On Fri, Dec 13, 2013 at 3:29 PM, Phil Steitz <ph...@gmail.com> wrote:
>>
>>> On 12/13/13, 11:34 AM, Gary Gregory wrote:
>>>> On Fri, Dec 13, 2013 at 12:57 AM, Phil Steitz <ph...@gmail.com>
>>> wrote:
>>>>> On 12/12/13, 6:50 PM, Gary Gregory wrote:
>>>>>> Hi All:
>>>>>>
>>>>>> We talk on and off as to how painful it is to release components.
>>>>>>
>>>>>> One of these pains is that we distribute to multiple places: An Apache
>>>>>> "dist" folder and the Apache Maven repository.
>>>>>>
>>>>>> Clearly, Maven is here to stay.
>>>>>>
>>>>>> So why not deploy the -src and -bin files to Maven and forget about
>>>>> dist. A
>>>>>> URL is a URL, what do users care is the URL points deep into "dist" or
>>>>> our
>>>>>> Maven repo. I for one, need the -bin zips for certain Apache projects
>>>>>> (JMeter, ActiveMQ) so my Ant Ivy builds can download and install them.
>>>>>>
>>>>>> I know we have some legal requirements to host at least the sources and
>>>>>> that we provide binaries as a "courtesy" but does it matter _where_ the
>>>>>> files are on Apache servers?
>>>>> The releases need to be mirrored. That's what dist is for.
>>>>>
>>>> How is this not the same thing that happens with the Maven repo, which is
>>>> mirrored all over as well? Please educate/correct me.
>>> See Mark's comments. We need to either say we are not directly
>>> providing artifacts to users (not acceptable, IMO),
>>
>> We are, for example:
>> https://repository.apache.org/content/repositories/releases/
>
> We should not be pointing users at that URL for download, because it
> is not a mirror reference (Mark or some infra@-knowledgeable person
> can correct me if I am wrong here). The mirrors exist in part to
> prevent ASF servers getting hammered by end-users trying to download
> artifacts. Pointing end-users to repo.a.o is pointing them directly
> at ASF infra, which is a no-no (because it does not take advantage
> of the load-distribution advantage of the mirroring system). As I
> said above, if we want to go this way, we will have to point them at
> maven central, which runs afoul of the requirement that Sebb
> references.
>>
>>
>>> or direct users
>>> to mirrors.
>>
>> Which could point to Maven Central and the like.
>>
>>
>> The way dist and the various download cgis work is that
>>> users are directed to download the artifacts from mirrors near them,
>>> not directly from ASF servers. I guess we could in theory direct
>>> them to maven central, but that makes me a little twitchy as we
>>> don't really control or monitor the process of mirroring there.
>>>
>> As noted above, we control
>> https://repository.apache.org/content/repositories/releases/
>
> Right, but we can't point end-users there, per comments above.
>
> Phil
>>
>> Gary
>>
>>
>>> So if we are going to distribute directly, we should continue to do
>>> it from dist. Mark also makes a good point about archives.
>>>
>> https://repository.apache.org/content/repositories/releases/ behaves like
>> an archive since it keeps old versions.
>>
>> Gary
>>
>>
>>> Phil
>>>> Thank you,
>>>> Gary
>>>>
>>>>
>>>>> Phil
>>>>>> Thoughts?
Moving artifacts from the dist/dev location to the release location was
indeed one of the problematic actions when doing the last [beanutils]
release - a whole bunch of commands had to be typed in, and for me it
did not work in the way it was described.
However, I think that this step could easily be scripted in some way. If
there was an easy and automated method for dealing with dist, there
would not be much point in searching for an alternative.
Oliver
>>>>>>
>>>>>> Gary
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] simplifying releases: dist vs. maven repo
Posted by Phil Steitz <ph...@gmail.com>.
On 12/13/13, 12:34 PM, Gary Gregory wrote:
> On Fri, Dec 13, 2013 at 3:29 PM, Phil Steitz <ph...@gmail.com> wrote:
>
>> On 12/13/13, 11:34 AM, Gary Gregory wrote:
>>> On Fri, Dec 13, 2013 at 12:57 AM, Phil Steitz <ph...@gmail.com>
>> wrote:
>>>> On 12/12/13, 6:50 PM, Gary Gregory wrote:
>>>>> Hi All:
>>>>>
>>>>> We talk on and off as to how painful it is to release components.
>>>>>
>>>>> One of these pains is that we distribute to multiple places: An Apache
>>>>> "dist" folder and the Apache Maven repository.
>>>>>
>>>>> Clearly, Maven is here to stay.
>>>>>
>>>>> So why not deploy the -src and -bin files to Maven and forget about
>>>> dist. A
>>>>> URL is a URL, what do users care is the URL points deep into "dist" or
>>>> our
>>>>> Maven repo. I for one, need the -bin zips for certain Apache projects
>>>>> (JMeter, ActiveMQ) so my Ant Ivy builds can download and install them.
>>>>>
>>>>> I know we have some legal requirements to host at least the sources and
>>>>> that we provide binaries as a "courtesy" but does it matter _where_ the
>>>>> files are on Apache servers?
>>>> The releases need to be mirrored. That's what dist is for.
>>>>
>>> How is this not the same thing that happens with the Maven repo, which is
>>> mirrored all over as well? Please educate/correct me.
>> See Mark's comments. We need to either say we are not directly
>> providing artifacts to users (not acceptable, IMO),
>
> We are, for example:
> https://repository.apache.org/content/repositories/releases/
We should not be pointing users at that URL for download, because it
is not a mirror reference (Mark or some infra@-knowledgeable person
can correct me if I am wrong here). The mirrors exist in part to
prevent ASF servers getting hammered by end-users trying to download
artifacts. Pointing end-users to repo.a.o is pointing them directly
at ASF infra, which is a no-no (because it does not take advantage
of the load-distribution advantage of the mirroring system). As I
said above, if we want to go this way, we will have to point them at
maven central, which runs afoul of the requirement that Sebb
references.
>
>
>> or direct users
>> to mirrors.
>
> Which could point to Maven Central and the like.
>
>
> The way dist and the various download cgis work is that
>> users are directed to download the artifacts from mirrors near them,
>> not directly from ASF servers. I guess we could in theory direct
>> them to maven central, but that makes me a little twitchy as we
>> don't really control or monitor the process of mirroring there.
>>
> As noted above, we control
> https://repository.apache.org/content/repositories/releases/
Right, but we can't point end-users there, per comments above.
Phil
>
> Gary
>
>
>> So if we are going to distribute directly, we should continue to do
>> it from dist. Mark also makes a good point about archives.
>>
> https://repository.apache.org/content/repositories/releases/ behaves like
> an archive since it keeps old versions.
>
> Gary
>
>
>> Phil
>>> Thank you,
>>> Gary
>>>
>>>
>>>> Phil
>>>>> Thoughts?
>>>>>
>>>>> Gary
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] simplifying releases: dist vs. maven repo
Posted by sebb <se...@gmail.com>.
On 13 December 2013 20:34, Gary Gregory <ga...@gmail.com> wrote:
> On Fri, Dec 13, 2013 at 3:29 PM, Phil Steitz <ph...@gmail.com> wrote:
>
>> On 12/13/13, 11:34 AM, Gary Gregory wrote:
>> > On Fri, Dec 13, 2013 at 12:57 AM, Phil Steitz <ph...@gmail.com>
>> wrote:
>> >
>> >> On 12/12/13, 6:50 PM, Gary Gregory wrote:
>> >>> Hi All:
>> >>>
>> >>> We talk on and off as to how painful it is to release components.
>> >>>
>> >>> One of these pains is that we distribute to multiple places: An Apache
>> >>> "dist" folder and the Apache Maven repository.
>> >>>
>> >>> Clearly, Maven is here to stay.
>> >>>
>> >>> So why not deploy the -src and -bin files to Maven and forget about
>> >> dist. A
>> >>> URL is a URL, what do users care is the URL points deep into "dist" or
>> >> our
>> >>> Maven repo. I for one, need the -bin zips for certain Apache projects
>> >>> (JMeter, ActiveMQ) so my Ant Ivy builds can download and install them.
>> >>>
>> >>> I know we have some legal requirements to host at least the sources and
>> >>> that we provide binaries as a "courtesy" but does it matter _where_ the
>> >>> files are on Apache servers?
>> >> The releases need to be mirrored. That's what dist is for.
>> >>
>> > How is this not the same thing that happens with the Maven repo, which is
>> > mirrored all over as well? Please educate/correct me.
>>
>> See Mark's comments. We need to either say we are not directly
>> providing artifacts to users (not acceptable, IMO),
>
>
> We are, for example:
> https://repository.apache.org/content/repositories/releases/
>
>
>> or direct users
>> to mirrors.
>
>
> Which could point to Maven Central and the like.
>
>
> The way dist and the various download cgis work is that
>> users are directed to download the artifacts from mirrors near them,
>> not directly from ASF servers. I guess we could in theory direct
>> them to maven central, but that makes me a little twitchy as we
>> don't really control or monitor the process of mirroring there.
>>
>
> As noted above, we control
> https://repository.apache.org/content/repositories/releases/
Control is *not* the issue here.
The ASF releases source, which MUST be made available via the ASF
mirror system [1]
If you want to change that requirement, AIUI you will have to get
agreement from the board.
[1] http://www.apache.org/dev/release.html#host-GA
> Gary
>
>
>>
>> So if we are going to distribute directly, we should continue to do
>> it from dist. Mark also makes a good point about archives.
>>
>
> https://repository.apache.org/content/repositories/releases/ behaves like
> an archive since it keeps old versions.
>
> Gary
>
>
>>
>> Phil
>> >
>> > Thank you,
>> > Gary
>> >
>> >
>> >> Phil
>> >>> Thoughts?
>> >>>
>> >>> Gary
>> >>>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >>
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] simplifying releases: dist vs. maven repo
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Dec 13, 2013 at 3:29 PM, Phil Steitz <ph...@gmail.com> wrote:
> On 12/13/13, 11:34 AM, Gary Gregory wrote:
> > On Fri, Dec 13, 2013 at 12:57 AM, Phil Steitz <ph...@gmail.com>
> wrote:
> >
> >> On 12/12/13, 6:50 PM, Gary Gregory wrote:
> >>> Hi All:
> >>>
> >>> We talk on and off as to how painful it is to release components.
> >>>
> >>> One of these pains is that we distribute to multiple places: An Apache
> >>> "dist" folder and the Apache Maven repository.
> >>>
> >>> Clearly, Maven is here to stay.
> >>>
> >>> So why not deploy the -src and -bin files to Maven and forget about
> >> dist. A
> >>> URL is a URL, what do users care is the URL points deep into "dist" or
> >> our
> >>> Maven repo. I for one, need the -bin zips for certain Apache projects
> >>> (JMeter, ActiveMQ) so my Ant Ivy builds can download and install them.
> >>>
> >>> I know we have some legal requirements to host at least the sources and
> >>> that we provide binaries as a "courtesy" but does it matter _where_ the
> >>> files are on Apache servers?
> >> The releases need to be mirrored. That's what dist is for.
> >>
> > How is this not the same thing that happens with the Maven repo, which is
> > mirrored all over as well? Please educate/correct me.
>
> See Mark's comments. We need to either say we are not directly
> providing artifacts to users (not acceptable, IMO),
We are, for example:
https://repository.apache.org/content/repositories/releases/
> or direct users
> to mirrors.
Which could point to Maven Central and the like.
The way dist and the various download cgis work is that
> users are directed to download the artifacts from mirrors near them,
> not directly from ASF servers. I guess we could in theory direct
> them to maven central, but that makes me a little twitchy as we
> don't really control or monitor the process of mirroring there.
>
As noted above, we control
https://repository.apache.org/content/repositories/releases/
Gary
>
> So if we are going to distribute directly, we should continue to do
> it from dist. Mark also makes a good point about archives.
>
https://repository.apache.org/content/repositories/releases/ behaves like
an archive since it keeps old versions.
Gary
>
> Phil
> >
> > Thank you,
> > Gary
> >
> >
> >> Phil
> >>> Thoughts?
> >>>
> >>> Gary
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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
Re: [all] simplifying releases: dist vs. maven repo
Posted by Phil Steitz <ph...@gmail.com>.
On 12/13/13, 11:34 AM, Gary Gregory wrote:
> On Fri, Dec 13, 2013 at 12:57 AM, Phil Steitz <ph...@gmail.com> wrote:
>
>> On 12/12/13, 6:50 PM, Gary Gregory wrote:
>>> Hi All:
>>>
>>> We talk on and off as to how painful it is to release components.
>>>
>>> One of these pains is that we distribute to multiple places: An Apache
>>> "dist" folder and the Apache Maven repository.
>>>
>>> Clearly, Maven is here to stay.
>>>
>>> So why not deploy the -src and -bin files to Maven and forget about
>> dist. A
>>> URL is a URL, what do users care is the URL points deep into "dist" or
>> our
>>> Maven repo. I for one, need the -bin zips for certain Apache projects
>>> (JMeter, ActiveMQ) so my Ant Ivy builds can download and install them.
>>>
>>> I know we have some legal requirements to host at least the sources and
>>> that we provide binaries as a "courtesy" but does it matter _where_ the
>>> files are on Apache servers?
>> The releases need to be mirrored. That's what dist is for.
>>
> How is this not the same thing that happens with the Maven repo, which is
> mirrored all over as well? Please educate/correct me.
See Mark's comments. We need to either say we are not directly
providing artifacts to users (not acceptable, IMO), or direct users
to mirrors. The way dist and the various download cgis work is that
users are directed to download the artifacts from mirrors near them,
not directly from ASF servers. I guess we could in theory direct
them to maven central, but that makes me a little twitchy as we
don't really control or monitor the process of mirroring there.
So if we are going to distribute directly, we should continue to do
it from dist. Mark also makes a good point about archives.
Phil
>
> Thank you,
> Gary
>
>
>> Phil
>>> Thoughts?
>>>
>>> Gary
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] simplifying releases: dist vs. maven repo
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Dec 13, 2013 at 12:57 AM, Phil Steitz <ph...@gmail.com> wrote:
> On 12/12/13, 6:50 PM, Gary Gregory wrote:
> > Hi All:
> >
> > We talk on and off as to how painful it is to release components.
> >
> > One of these pains is that we distribute to multiple places: An Apache
> > "dist" folder and the Apache Maven repository.
> >
> > Clearly, Maven is here to stay.
> >
> > So why not deploy the -src and -bin files to Maven and forget about
> dist. A
> > URL is a URL, what do users care is the URL points deep into "dist" or
> our
> > Maven repo. I for one, need the -bin zips for certain Apache projects
> > (JMeter, ActiveMQ) so my Ant Ivy builds can download and install them.
> >
> > I know we have some legal requirements to host at least the sources and
> > that we provide binaries as a "courtesy" but does it matter _where_ the
> > files are on Apache servers?
>
> The releases need to be mirrored. That's what dist is for.
>
How is this not the same thing that happens with the Maven repo, which is
mirrored all over as well? Please educate/correct me.
Thank you,
Gary
>
> Phil
> >
> > Thoughts?
> >
> > Gary
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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
Re: [all] simplifying releases: dist vs. maven repo
Posted by Phil Steitz <ph...@gmail.com>.
On 12/12/13, 6:50 PM, Gary Gregory wrote:
> Hi All:
>
> We talk on and off as to how painful it is to release components.
>
> One of these pains is that we distribute to multiple places: An Apache
> "dist" folder and the Apache Maven repository.
>
> Clearly, Maven is here to stay.
>
> So why not deploy the -src and -bin files to Maven and forget about dist. A
> URL is a URL, what do users care is the URL points deep into "dist" or our
> Maven repo. I for one, need the -bin zips for certain Apache projects
> (JMeter, ActiveMQ) so my Ant Ivy builds can download and install them.
>
> I know we have some legal requirements to host at least the sources and
> that we provide binaries as a "courtesy" but does it matter _where_ the
> files are on Apache servers?
The releases need to be mirrored. That's what dist is for.
Phil
>
> Thoughts?
>
> Gary
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] simplifying releases: dist vs. maven repo
Posted by Mark Thomas <ma...@apache.org>.
On 13/12/2013 02:50, Gary Gregory wrote:
> Hi All:
>
> We talk on and off as to how painful it is to release components.
>
> One of these pains is that we distribute to multiple places: An Apache
> "dist" folder and the Apache Maven repository.
>
> Clearly, Maven is here to stay.
>
> So why not deploy the -src and -bin files to Maven and forget about dist. A
> URL is a URL, what do users care is the URL points deep into "dist" or our
> Maven repo. I for one, need the -bin zips for certain Apache projects
> (JMeter, ActiveMQ) so my Ant Ivy builds can download and install them.
It does seem to be an abuse of what the Maven repo is meant to be for
but lots of projects do it. When Tomcat had an explicit request for this
(and the .exe installer as well) I took a look at what was in the Maven
repo. Quite a few projects have been doing this for a while.
My conclusion was that given that:
a) Maven central don't object to it
b) it is easy to do
c) (some of) our users want it
then we should do it.
The fact that folks are using something in a way that wasn't originally
intended is - to me - far less important.
> I know we have some legal requirements to host at least the sources and
> that we provide binaries as a "courtesy" but does it matter _where_ the
> files are on Apache servers?
We do need to keep the files on dist for so:
a) the mirrors can pick them up
b) they get automatically copied to archive.a.o
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org