commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [all] simplifying releases: dist vs. maven repo
Date Sat, 14 Dec 2013 00:26:59 GMT
On 13 December 2013 20:34, Gary Gregory <garydgregory@gmail.com> wrote:
> On Fri, Dec 13, 2013 at 3:29 PM, Phil Steitz <phil.steitz@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.steitz@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/
>
>
>> 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/

Control is *not* the issue here.

The ASF releases source, which MUST be made available via the ASF
mirror system [1]

If you want to change that requirement, AIUI you will have to get
agreement from the board.

[1] http://www.apache.org/dev/release.html#host-GA

> 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?
>> >>>
>> >>> 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
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message