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 <phil.ste...@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.ste...@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-unsubscr...@commons.apache.org >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
