commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [all] simplifying releases: dist vs. maven repo
Date Sun, 15 Dec 2013 21:29:31 GMT
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 <phil.steitz@gmail.com> wrote:
>>>
>>>> On 12/13/13, 11:34 AM, Gary Gregory wrote:
>>>>> On Fri, Dec 13, 2013 at 12:57 AM, Phil Steitz <phil.steitz@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


Mime
View raw message