On Fri, Mar 15, 2013 at 11:14 AM, Patrick Schlebusch < [email protected]> wrote:
> Thomas Broyer wrote at some time: > > Because a class in A transitively depends on a class provided by C then > it > > *has* to know about C. Class hierarchy is part of the API (which is one > > reason you should generally prefer composition over inheritance). > > The compiler needs to know about artifact C of course. But I as the > consumer of artifact B should not need to know B's dependencies. Actually > I thought this was the reason for the whole automatic resolution of > transitive dependencies. This is not for convenience, it hides internal > details of B from A. > If the class from C is part of the API of B, then it's not an "internal detail". Otherwise that would mean I would need to first look at the POMs of all my > dependencies and basically copy all provided scope dependencies to my > project. Which kind of reminds me of software development without Maven. > I understand your concern; I'm just not sure this should be seen as a bug. Also note that if scope=provided is redefined as being transitive at compile-time (i.e. when resolving dependencies for the compile scope) but not runtime (i.e. packaging time actually) –you'd probably want to also make it transitive at test-time–, that means annotation processors would have to live in some other scope: because I use JPA2 (e.g. Hibernate) or JSR330 (e.g. Dagger) annotation processors in my project doesn't mean downstream projects want to use them. In other words, that'd be a breaking change. Maybe adding a new <transitive>true</transitive> to <dependency> would work… Either that or creating a new scope (but then how would you call it? "provided" would be great, but it already means "compile-only"). Now maybe the issue is in the maven-bundle-plugin and how it integrates with Maven when resolving dependencies through Maven rather than OSGI: AIUI (I don't do OSGI), scope=compile for a bundle means "bundle it in the JAR, and possibly expose its classes/packages" which should thus not be transitive, whereas you use scope=provided to mean "don't bundle it, it'll be provided as an OSGI bundle at runtime" and you thus would like it to be transitive when resolved by Maven. The problem seems to be that Maven has the notion that a packaging type either "includesDependencies" or not, whereas OSGI bundles can do both. But maybe the maven-bundle-plugin should just use a special scope (e.g. scope=bundle) for things that will be bundled, rather than scope=provided (the tomcat-maven-plugin uses a scope=tomcat for WARs you want to automatically deploy to the test-server with tomcat7:run, so it's entirely possible to do something similar at the maven-bundle-plugin) But as I said, I don't know OSGI much, and don't know the maven-bundle-plugin and bundle packaging, but it looks more like an impedance mismatch between OSGI and Maven and/or a bad integration, and thus a bug in the maven-bundle-plugin rather than Maven itself. -- Thomas Broyer /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
