"Davanum Srinivas" <[EMAIL PROTECTED]> writes: > #1) End user using an Incubator podling m2 artifact directly: End > users need to specify our repo in their pom.xml explicity. this is a > conscious decision. > > #2) End user using a regular Apache project that depends on incubator > podling artifact: End users won't have to touch their pom.xml and the > podling jars are automatically downloaded. So we lose the benefit > here. > > *BUT* here's what we can do to make #2 a conscious decision. Say > Axis2...we depend on woden. If we mark woden jar with scope=provided > [1], then the end user has to do a conscious import just like they did > in #1. So there is a way to enforce the policy if we wish.
The end user in situation #2 is trusting the Apache project (ie- Axis) and shouldn't have to care whether it includes incubating code. Just as the user shouldn't have to deal with separate downloads if, say, Axis includes MPL licensed code as per the legal guidelines. The PMC made the decision to trust the incubating code and released it. If the PMC feels it needs to warn it's users, it should include something in it's release documentation. (Axis PMC here just being an example of _any_ TPL PMC). -- jaaron --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
