commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [all] simplifying releases: dist vs. maven repo
Date Mon, 16 Dec 2013 20:32:42 GMT

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 <>
>>>>> On 12/13/13, 11:34 AM, Gary Gregory wrote:
>>>>>> On Fri, Dec 13, 2013 at 12:57 AM, Phil Steitz <>
>>>>> 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
>>>>>>> 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
>>>>>>>> (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:
>>> 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
>>> 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.
>>>> 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.


> Phil
> [1]
>> Oliver
>>>>>>>> Gary
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail:
>>>>>>> For additional commands, e-mail:
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:
>>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message