incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gwyn Evans" <gwyn.ev...@gmail.com>
Subject Re: Killing the incubator m2 repository
Date Fri, 16 Mar 2007 14:58:29 GMT
Surely there are no "actual instances" as yet, as this sub-thread's
about the effect of the suggested "<scope>provided</scope>" if it were
to be used...

/Gwyn

On 16/03/07, Davanum Srinivas <davanum@gmail.com> wrote:
> Daniel,
>
> Before we take on the branding question. Can you please whip up some
> actual instances of where the ["less pleasant" for users of apache
> project] happened/reported? Let's get some clarity here on what is
> being done here...is it an effort to gain legitimacy w/o exiting
> incubation or really caring about end users or something else
> entirely.
>
> thanks,
> dims
>
> On 3/16/07, Daniel Kulp <daniel.kulp@iona.com> wrote:
> > On Friday 16 March 2007 10:06, Davanum Srinivas wrote:
> > > 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.
> >
> > Right, but that again defeats the whole point of having the incubator
> > repository.   If other projects can easily bypass the requirement that
> > people "opt in" to incubator artifacts, then the users of those projects
> > still wouldn't know they are using incubator artifacts unless they look
> > at the dependencies report.   For them, it would make no difference
> > whether the artifacts came from central or p.a.o.  (other than the build
> > is slower coming from p.a.o)
> >
> > You basically make it "less pleasant" for users of apache projects, but
> > have no affect on others.   Is that good for the Apache brand?
> >
> > Dan
> >
> >
> > >
> > > 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
> >
> > --
> > 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
>
>


-- 
Download Wicket 1.2.5 now! - http://wicketframework.org

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


Mime
View raw message