As Gwyn said, if we go the <scope>provided</scope> route, this issue would come up. Since we haven't done that yet, there isn't an instance. If we go that route, all the Axis/Geronimo/etc... developers and users would be impacted, but no-one on projects outside of Apache would be impacted at all as they could just ignore the "provided" recommendation. That would result in "positive" experiences for outside projects, negative for Apache projects. Not good IMO.
Dan On Friday 16 March 2007 10:45, Davanum Srinivas 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: > > > > > > [EMAIL PROTECTED] For additional > > > > > > commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > > > > J. Daniel Kulp > > > > Principal Engineer > > > > IONA > > > > P: 781-902-8727 C: 508-380-7194 > > > > [EMAIL PROTECTED] > > > > http://www.dankulp.com/blog > > > > > > > > ---------------------------------------------------------------- > > > >---- - To unsubscribe, e-mail: > > > > [EMAIL PROTECTED] For additional > > > > commands, e-mail: [EMAIL PROTECTED] > > > > -- > > J. Daniel Kulp > > Principal Engineer > > IONA > > P: 781-902-8727 C: 508-380-7194 > > [EMAIL PROTECTED] > > http://www.dankulp.com/blog > > > > -------------------------------------------------------------------- > >- To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
