2009/3/12 Filippo Diotalevi <[email protected]> > Hi, > I'm experiencing an intermittent, weird problem with the Maven > Bundle Plugin. It happens only on one machine (regularly on that > machine, Ubuntu, JDK1.6). > > When I build a bundle, some classes are actually built (there's the > class in /target/classes/) BUT they're not included in the final jar. >
first make sure you read all the docs: http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html the only classes that will appear in the bundle are the ones you ask it to include using Export-Package, Private-Package, Include-Resource, and Embed-Dependency - so just because a file exists under target/classes does NOT mean it will end up in the bundle. this is because this is the way the underlying BND tool works (pull-based) now the bundleplugin will look at your Maven project and add appropriate BND instructions to pull in resource files - and version 2.0.0 will also look at your source directory to set reasonable defaults for Export-Package and Private-Package (unless you set these yourself) so when using bundleplugin 2.0.0 I'd use the default Private-Package and Export-Package to begin with - I would then move towards using an explicit list of packages in Export-Package to add versioning, directives, etc. the only time I would set Private-Package would be to have more control over what ends up in the bundle - either to remove certain packages or perhaps pull in additional packages not found by the source scanner. also note that both Export-Package and Private-Package accept wildcards such as "org.example.*" which can reduce the number of entries in the list, but you should be careful not to set either the export or private instruction to "*" as this would pull in the entire classpath... dependencies and all! << please note this is a full response so I can paste it into an FAQ >> > If I change the packaging to jar, classes are, on the contrary, all > included in the jar. > > Can it be a problem in the configuration/pom? > > The POM is really simple: > > <?xml version="1.0"?><project> > <parent> > <artifactId>engine</artifactId> > <groupId>....</groupId> > <version>0.0.1-SNAPSHOT</version> > </parent> > <modelVersion>4.0.0</modelVersion> > <groupId>.....</groupId> > <artifactId>bundle.authorization</artifactId> > <packaging>bundle</packaging> > <name>bundle.authorization</name> > <version>0.0.1-SNAPSHOT</version> > <build> > <plugins> > <plugin> > <groupId>org.apache.felix</groupId> > <artifactId>maven-bundle-plugin</artifactId> > <extensions>true</extensions> > <configuration> > <instructions> > > <Private-Package>......engine.bundle.authorization</Private-Package> check to see if the package for the missed classes appears in your current Private-Package list - if it does then something else is going on which stops the BND tool from adding the files to the bundle, if not then to get this class pulled in you'll need to add the package to the Private-Package list a complete run with "mvn clean install -X" to produce a complete debug log might help - with bundleplugin 2.0.0 this will also provide information about the instructions sent to BND and the generated manifests also note that the Java compiler can sometimes generate classes inside the target directory for non-local source - this can happen if a pom includes the source directory as a resource directory, for example see: http://mail-archives.apache.org/mod_mbox/felix-users/200809.mbox/%[email protected]%3e I guess similar things could happen if your source code is being updated while the build is going on, so another question is whether the class in target/classes comes from the local project (ie. src/main/java) or elsewhere... HTH </instructions> > </configuration> > </plugin> > <plugin> > <groupId>org.apache.maven.plugins</groupId> > <artifactId>maven-compiler-plugin</artifactId> > <configuration> > <target>1.5</target> > <source>1.5</source> > </configuration> > </plugin> > </plugins> > </build> > <dependencies> > <dependency> > .... > > Thanks, > -- > Filippo Diotalevi > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Cheers, Stuart
