Why package deps won't work (Was: Re: Converting plain JARs to Java modules)

[Nicolas Lalevée]

Hi guys,

Thank you for this very interesting discussion. I'll just react on a particular point and an example you raised.

Le 15 nov. 2011 à 06:14, David M. Lloyd a écrit :

> Yes, and it is actually fairly common in practice to want two versions of something in the sense of the two versions being wholly different implementations (think apache commons logging versus jcl-over-slf4j for a trivial example which crops up a lot).  There are reasons to use one or the other.  Multiplicity of versions (in this respect) is something the module system has to handle gracefully and simply.

Then how a m2m solution is expected to resolve such case where a module is declaring a dependency on "commons-logging", whereas at deployment time I want "jcl-over-slf4j" instead ?

With Maven/Ivy, some exclude rule can be set to build the classpath. Then at runtime the jvm just see one classpath and not the "module" declaration, so everything work then fine.
An OSGi runtime being aware of the modules/bundle, you cannot really trick it with exclude rules. If you do, then what's the point of declaring them in the first place ? It is like tricking the jvm and declare that ch.qos.logback.classic.Logger is the substitute of org.apache.commons.logging.Log. Expressing dependencies on APIs, package in the OSGi space, then the modules can correctly bind each other without any overridden declaration.

I think that was the main point of Peter's mail, API vs implementation. "Package" and "Bundle" is the way of declaring module level API and Implementation in OSGi. I can imagine than in a m2m solution it would be possible to invent special kind of module which would be about declaring APIs, just like Java Interfaces are to Java Classes. I don't know much about JBoss Modules, but such "Module Interface" doesn't exist there, does it ? How the slf4j libraries are handled in JBoss Modules world ?

Nicolas