Hi Felix > > Let's see: Obvisouly you only pack a single package (the exported > ch.ipi.earexample.api) into the bundle. The maven bundle > plugin analyzes > these classes and calculates the dependencies, which seem to just be > javax.ejb (except re-importing the exported classes). > > So you are API package does not have a dependency on the Commons Lang > package and hence there is no Import-Package entry for it.
Ok, now I understand! I added the Commons Lang dependency only in the POM as an example, but didn't really use it in my interface. Now I've added another method which uses the ToStringBuilder, and I get Manifest-Version: 1.0 Export-Package: ch.ipi.earexample.api;uses:="javax.ejb,org.apache.comm ons.lang.builder" Built-By: lewis_lee Tool: Bnd-0.0.255 Bundle-Name: ear-example-api Created-By: Apache Maven Bundle Plugin Bundle-Vendor: Swiss Federal Institute of Intellectual Property Build-Jdk: 1.6.0_07 Bundle-Version: 1.0.0.SNAPSHOT Bnd-LastModified: 1229096385549 Bundle-ManifestVersion: 2 Bundle-Activator: ch.ipi.earexample.api.Activator Bundle-Description: A simple EAR Bundle-DocURL: http://www.ipi.ch Bundle-SymbolicName: ch.ipi.ear-example-api Import-Package: ch.ipi.earexample.api,javax.ejb,org.apache.commons.lan g.builder;version="2.4" Smart! So effectively, only the packages which are really used are shown as bundle dependencies, right? > > Also, what is the strategy concerning the dependency > bundles? My idea > > was that the server API defines its dependencies as OSGI > bundles. But if > > they aren't included in the created JAR and the OSGI platform has to > > figure out where to get those packages, they have to be present as > > bundles in some known directory, right? > > As I understand the API itself does not need nor use the commons lang > library. It is some implementation of that API making use of this > library. Therefore that implementation will have to declare the > dependency. And this is good, because the use of the commons lang > library seems to be an implementation detail unrelated to the > actual API. Well, as I said, it was only a bogus dependency. Things are now clearer. > Now, if your implementation uses the common lang library, the > implementation will either include that library (as per > Embed-Dependency > for example) or import it with Import-Package (generated by the maven > bundle plugin automatically). What you effectively do, depends on your > requirement and the circumstances. > > For example, in the case of a library such as commons lang or commons > collections, I would use the import apporach and deploy the > libraries as > separate bundles into the framework. In the case of for > example JDOM, I > would probably rather embed it and use it from within. Since we want all external dependencies to exist only once, we'll use Import-Package and have the bundles containing e.g. Commons Lang ready at runtime. > > We're building an RCP client, and for various reasons, we > just call the > > usual PDE build from Maven. To have at least a bit of dependency > > management, my idea was to have just one POM for the whole > client (with > > all features, plugins etc. below, but not touched by Maven) > where all > > those dependencies are referenced as bundles. However, this > would mean > > that they're defined both in the API and somewhere in the > client, which > > is not very nice :-) Is my idea wrong or is there an easier way to > > handle this? > > Hmm, I do not quite understand, what you need mavens dependency > management for, then. Since you then seem to declare the > dependencies in > two places (and trying to sync is an endless job), the > MANIFEST through > PDE functionality and the maven POM. > > In addition, maven does not reference dependencies as bundles, this > confuses me bit ;-) > > Finally, I do not understand, why listing dependencies in a POM, which > is used to call the PDE build, has an influence on an dependencies of > the API. Well, perhaps my ideas a weird ;-) but I figured that since my client needs my API and my API needs Commons Lang and since the Commons Lang bundle is the same as the normal Commons Lang JAR with some OSGI information, I might as well use the bundle in the API (they are available from the SpringSource Maven repository anyway). Otherwise my API would use the normal Commons Lang (downloaded by Maven into our repository) and by the Import-Package the client would be forced to use the Commons Lang bundle (also downloaded by whoever), making the same thing (Commons Lang) exist in two files and in two places. As for the normal PDE build: The plugins declare their dependencies, and (if I'm not mistaken) the map file declares where to get them. Since we from the build team want to have some control about what libraries are used, we define that any library which exists in our Master (Parent) POM can be used, and this goes for the client as well. So yes, the client developers would have to define a new library in the client POM, then it's downloaded by Maven and copied (or whatever) for the PDE build and for the Eclipse plugin projects to use. Best regards, Eric --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
