On Thursday, 14 March 2013, Jörg Schaible wrote: > Patrick Schlebusch wrote: > > > Hi everyone, > > > > we're using Maven to build OSGi bundles among other types of artifacts. > In > > this context we have run into some problems related to provided scope > > dependencies. > > > > The documentation [1] about the provided scope says: "This is much like > > compile, but indicates you expect the JDK or a container to provide the > > dependency at runtime." > > There is also the following note about transitive compile dependencies: " > > it is intended that this should be runtime scope instead, so that all > > compile dependencies must be explicitly listed - however, there is the > > case where the library you depend on extends a class from another > library, > > forcing you to have available at compile time. For this reason, compile > > time dependencies remain as compile scope even when they are transitive." > > > > In the same way, Mavens current behaviour leads to problems if an > artifact > > extends a class of a provided scope dependency. I hope this little > example > > makes this clearer: > > > > Lets assume we have the artifacts A, B and C. B depends on C with scope > > provided. B contains a class that extends a class of C. If A wants to use > > this class of B, it should only need to add a dependency for B (lets > > assume compile scope here). However, since provided scopes are not > > resolved transitively A cannot be compiled without also specifying a > > dependency on C, an artifact it shouldn't have to know about. > > > > I know this is not a new issue in any way; there is a 7 year old Jira > [2], > > which has some discussion, but seems to have no conclusion in any way and > > is not scheduled to be fixed. > > > > Are there any workarounds for this except for maybe using a patched Maven > > version? Is there any 'official' opinion on this? I would also be > > interested in the reasoning behind making the provided scope > > non-transitive. > > Provided means "provided by the runtime environment".
I would change this to "provided means 'provided by either the runtime environment or a consumer of the project declaring the dependency'" In other words the provision of the dependency is not the problem of this projects transitive dependency tree... You may have a downstream project that lists this project as a dependency and also adds the provided dependencies as its own 'runtime' scope dependencies, so it need not be the runtime environment that provides the dependency, but the scope declares that *this* project does not care where it comes from ;-) > If I use > javax.mail:mail, I add it to my dependency list as provided, when I know > that my target platform is JEE. I should not have this jar in my war files, > because the classes are provided by the JEE environment. Clear? > > - Jörg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] <javascript:;> > For additional commands, e-mail: [email protected]<javascript:;> > > -- Sent from my phone
