...
No Format |
---|
<plugin> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.4</source> <target>1.4</target> </configuration> </plugin> |
When I build a bundle, some classes are built in "target/classes" but they're not included in the final jar.
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 (it is primarily 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!