Thomas Broyer wrote: > If the class from C is part of the API of B, then it's not an "internal > detail".
But C isn't necessarily part of the API of B and might still be required. (think inheriting protected methods for example) I would also argue that even if it is part of the API of B this can be an internal detail that I might want to legitimately hide: If C changes I might want to keep the API of B stable and just adapt B to changes in C internally. This is especially important if we're not talking about one artifact A that depends on B, but several. > 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. Surely there is a bit of an impedance mismatch, but it would be much more manageable if provided scope dependencies were transitive. However my argument for this is not that it makes OSGi development easier, but that any dependency required at compile-time should be transitive. The examples I described seem to have been considered in the behaviour of the compile scope (which is why I quoted the note from the table about transitive dependencies [1] in my first post). To me it just seems inconsistent and wrong to not consider those in provided scope dependencies. I fully understand that Maven has to keep compatibility with many, many existing builds, but at least in my opinion this is an issue which should be considered to be fixed in some way (be it the <transitive> property or a new scope or anything else). > 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) This is an interesting idea. I think I will kick off a discussion over there. Best regards, Patrick [1] http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope From: Thomas Broyer <[email protected]> To: Maven Users List <[email protected]>, Date: 15.03.2013 17:24 Subject: Re: Provided scope dependencies 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/> -------------------------------------------------------------------------------------------------------------------------------------------- Patrick Schlebusch - KISTERS AG - Charlottenburger Allee 5 - 52068 Aachen - Germany Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns Kisters | Aufsichtsratsvorsitzender: Dr. Thomas Klevers Tel.: +49 241 9671 -466 | Fax: +49 241 9671 -555 | E-Mail: [email protected] | WWW: http://www.kisters.de -------------------------------------------------------------------------------------------------------------------------------------------- Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
