Return-Path: X-Original-To: apmail-commons-dev-archive@www.apache.org Delivered-To: apmail-commons-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A0F0D10D7C for ; Sat, 14 Dec 2013 20:02:31 +0000 (UTC) Received: (qmail 18652 invoked by uid 500); 14 Dec 2013 20:02:30 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 18499 invoked by uid 500); 14 Dec 2013 20:02:30 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 18491 invoked by uid 99); 14 Dec 2013 20:02:29 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 14 Dec 2013 20:02:29 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [212.227.17.8] (HELO moutng.kundenserver.de) (212.227.17.8) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 14 Dec 2013 20:02:21 +0000 Received: from [192.168.0.101] (ip-95-223-202-55.unitymediagroup.de [95.223.202.55]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0ME24x-1VkzmI18k3-00HR28; Sat, 14 Dec 2013 21:02:01 +0100 Message-ID: <52ACB934.7050206@oliver-heger.de> Date: Sat, 14 Dec 2013 21:01:56 +0100 From: Oliver Heger User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Commons Developers List Subject: Re: [all] simplifying releases: dist vs. maven repo References: <52AAA1C7.6080409@gmail.com> <52AB6E0E.4080108@gmail.com> <52ABDC72.7070606@gmail.com> In-Reply-To: <52ABDC72.7070606@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:ps3p0fCL/lE8Zx/02J5shB+iFMcQyvcyOsNI25h7XHu 7KNjIlRsUQgcItDdKrrHk1zlZkP6tP33FJDdqlAZzFGgrKg292 jnRToCYlY35Bt64UDOHezd18gXcVEZo0EkqxASn1ajiMEeX5Ql E5kkcwI9bBRjs0fsDn/ZRhxHoH6lQMZmtXuGB4fxr4uhN5mf70 +MdtFWq7woLjVHhodfYO3GkMIazbsYDwoMi+fAZ1QB2r0woJHb ItENjjj7IdDi/Dp+LQDcV2cRabWpSHCYA4c6FeEzVYiVH9I0G4 s5eNlF/7UwLTcysGT6witikJYREjxDULxSMLBDx4vTAT+JHvCY k9FiZaQ/EOe8YuE+2kes= X-Virus-Checked: Checked by ClamAV on apache.org 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 wrote: >> >>> 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 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-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