Hi Eric, Lewis, Eric schrieb: > Hi Felix > > First of all, thanks for your reply! > >>> Let's say my API uses other libraries, like Commons Lang. >> The default >>> way that Felix offers is to include all Maven dependencies >> as JARs in >>> the bundle JAR. This works, but I don't see the point in >> having the same >>> JAR over and over again in separate bundles. Maybe someone >> can explain >>> this to me. >> This is AFACT not the default. The default is defined Import-Package >> statements for the dependent library packages. These imports will then >> have to be resolved by appropriate exports in the OSGi framework. > > Yes, sorry, I forgot to mention my plugin configuration, which includes > <Embed-Dependency>*;scope=compile|runtime</Embed-Dependency> > <Embed-Transitive>true</Embed-Transitive> > > But for the following results, this is no longer part of the > configuration.
ok. > >> So for example if you deploy a bundleized Commons Lang >> library (IIRC the >> Apache Commons project will release new versions with >> appropriate bundle >> headers out of the box), that bundle will export the lang packages, >> which will be used by your bundle. >> >> You may of course decide to include your dependencies (or >> some of them) >> into your bundle and not import it from the framework. This depends a >> bit on the use case. But in the case of your API bundle, it >> is probably >> more appropriate to just Import-Package the dependencies. >> >> >> You should not use Require-Bundle. See [1] for an excellent >> description, >> why. Rather let the maven-bundle-plugin generate the required >> Import-Package headers for you and let the OSGi framework resolve the >> dependencies. >> >> Hope this helps. >> >> Regards >> Felix >> >> [1] http://www.aqute.biz/Blog/2006-04-29 > > Well, this is my POM (excerpt): > > <dependencies> > <dependency> > <groupId>org.apache.commons</groupId> > <artifactId>com.springsource.org.apache.commons.lang</artifactId> > <version>2.4.0</version> > </dependency> > </dependencies> > > <build> > <plugins> > <plugin> > <groupId>org.apache.felix</groupId> > <artifactId>maven-bundle-plugin</artifactId> > <extensions>true</extensions> > <configuration> > <instructions> > <Export-Package>ch.ipi.earexample.api</Export-Package> > <Private-Package></Private-Package> > > <Bundle-Activator>ch.ipi.earexample.api.Activator</Bundle-Activator> > </instructions> > </configuration> > </plugin> > </plugins> > </build> > > Now, if I understand you correctly, the 'MANIFEST.MF' should > automatically contain 'Import-Package' information for the Commons Lang > packages? > Well, running 'mvn package' gives me this: > > Manifest-Version: 1.0 > Export-Package: ch.ipi.earexample.api;uses:="javax.ejb" > 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: 1229082128327 > 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 > > I don't see any Commons Lang packages. Do I have to configure > <Import-Package> separately? 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. > > > 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. 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. > > 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. Hope this helps. Regards Felix --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
