incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <daniel.k...@iona.com>
Subject Re: Killing the incubator m2 repository
Date Fri, 16 Mar 2007 13:59:26 GMT

So basically, the Incubator PMC now wants to start defining policies to 
control the actions of other top level Apache projects on how 
dependencies are made?

What about projects at codehaus.org?   How about sourceforge?  Google? 
ObjectWeb?

I'll take Woden as an example.   As pretty much the only pure java WSDL 
2.0 implementation, there's probably a bunch of projects OUTSIDE of 
apache that will require it.   Are you going to go and tell them all 
they have to use <scope>provided</scope>?   Isn't that some sort of 
restriction that the ASL is supposed to prevent?   What's to stop them 
from ignoring you?   Absolutely nothing.    Anyone that takes a 
dependency on those projects could/would get an incubator artifact 
without explicitly asking for/authorizing it.

Dan


On Friday 16 March 2007 09:42, Davanum Srinivas wrote:
> Noel,
>
> Please see below:
>
> On 3/16/07, Noel J. Bergman <noel@devtech.com> wrote:
> > Davanum Srinivas wrote:
> > > Yes, If the apache projects like say Axis2 and Geronimo set up
> > > their pom's in a certain fashion (using m2's scope=provided
> > > mechanism), end users will have to add incubator repos
> > > explicitly/consciously and won't get podling jars pulled in w/o
> > > their knowledge.
> >
> > What's the burden imposed by this on the user?  Does this mean that
> > we could eliminate the Incubator specific repository in favor of
> > <scope>provided</scope>?
>
> The burden on the user is that if he really wants to use that
> artifact, he/she should add it in their own pom's and add the
> repository also in their pom explicitly.
>
> > And is this an appropriate thing, since if Axis2
> > or Geronimo do that, doesn't it mean that the jar is no longer
> > packaged with them when they release?
>
> No, this means that the dist may have the jars. We are focusing on
> stopping users from auto-magically pulling in incubator artifacts via
> m2 dependency mechansims w/o their cooperation.
>
> > Is that an issue?
>
> Depends on who you ask :) Right?
>
> > If the goals are to help protect users from a naive (as contrasted
> > with an informed) dependence on projects that haven't yet earned
> > their ASF-status, and to ensure that Incubator projects aren't just
> > trying to cash in on the ASF-brand without adopting our methods,
> > where are the appropriate lines of control?
>
> We need to add some guidelines for how projects like Axis2 and
> Geronimo use incubator artifacts in addition to the guidelines in
> place for the Inucbator artifacts themselves.
>
> > If (for the sake of argument) WS decides to ship some Incubator JAR
> > as part of some WS release, and is supporting the release are they
> > counting on the Incubator JAR, or on you providing certain
> > functionality?
>
> They are counting on WS project. Case in point, woden is used for WSDL
> 2.0. If woden dies, Axis2 should come up with an alternative. For
> Geronimo, if cxf dies, there's always Axis2. FWIW, I really like how G
> balances rather juggles multiple options Tomcat/Jetty, Different
> flavors of JPA, Axis2/CXF etc.
>
> > Of course, that
> > ought to weigh into your own decision to include the JAR in the
> > first place. Would this be the same as a company using Roller in
> > production to sell a service while Roller was still in the
> > Incubator?  A service purchaser is expecting a blog, but perhaps not
> > counting on how that functionality is provided.  Should it depend on
> > whether the JAR's API is exposed, or simply some functionality that
> > you can maintain/replace?  Again, reflecting back on the goals.
>
> Yes, existing projects should exercise caution and plan for failures.
>
> >         --- Noel
> >
> >
> >
> > --------------------------------------------------------------------
> >- To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message