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