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