incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <dava...@gmail.com>
Subject Re: Killing the incubator m2 repository
Date Fri, 16 Mar 2007 14:06:08 GMT
Incubator PMC will set guidelines for incubator projects and will set
best practices (not obligatory) to other ASF projects. Everyone else
can do what they want.

thanks,
dims

On 3/16/07, Daniel Kulp <daniel.kulp@iona.com> wrote:
>
> 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
>
>


-- 
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers

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


Mime
View raw message