incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <>
Subject Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Date Tue, 16 Sep 2008 22:49:04 GMT
On Tue, Sep 16, 2008 at 2:10 PM, William A. Rowe, Jr.

> Justin Erenkrantz wrote:
>> On Mon, Sep 15, 2008 at 11:13 AM, Emmanuel Lecharny <>
>> wrote:
>>> Craig L Russell wrote:
>>>> -1
>>>> I believe that allowing incubating releases to be treated as full Apache
>>>> releases diminishes the Apache brand and makes incubation disclaimers
>>>> moot.
>>>> With Maven, it is too easy to depend on a release with transitive
>>>> dependencies on incubating releases without even knowing it. When the
>>>> incubating release subsequently is abandoned, blame will be cast widely,
>>>> including Apache itself.
>>>> Considering that dependencies on incubating releases can be resolved by
>>>> explicitly adding an incubating Maven repository into your settings, I
>>>> don't
>>>> think that wide, mirrored, distribution is warranted.
>>>> Craig
>>> -1 too, for the same reasons.
>> -1.  Craig pointed out my objections as well.  -- justin
> Just so everyone understands this in context, the objection above is moot
> because...
> ...maven is a package deployment mechanism

Beg your pardon? I know that the homepage casts a wide net ("Maven is a
software project management and comprehension tool.") but in my book Maven
is used to build stuff (which happens to be almost exclusively Java). I
don't know of anybody who goes to actual users and tell them "here you go,
unzip that stuff there, set your JAVA_HOME and your MAVEN_HOME properly,
execute 'mvn install' and once all test cases pass you're golden".

Maven is a build tool. Users don't build, developers do. And developers
should know about licenses and disclaimers.


> ...developers who determine what to bundle into their package don't spend
>   a whole lot of time explaining to users that something within their
>   package is 'incubating' code, or 'patched/forked' code, or virgin
>   original code
> ...the developer who deploys an app is either going to explain it contains
>   an incubating artifact to their users, or they won't
> matter if the developer bundles an incubating jar, or calls it up
>   out of maven...
> The user has ***exactly*** the same experience.
> Presenting a user with a dialog "Package FOO requires the BAR.jar, an
> Apache Incubating Bar Project artifact, which[1] carries 'the'[2]
> disclaimer" will leave them utterly befuddled and is entirely worthless
> information in the context that they install package FOO (nevermind that
> the "actual" disclaimer appears to be non-existent in our release
> documentation).
> We permit GPL, commercial, virtual anything to be deposited into Maven
> if I understand correctly.  WTF not incubation artifacts, in that light?
> Bill
> [1] alternately... "is a tasty beverage container"
> [2]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message