Feeds:
Posts
Comments

Posts Tagged ‘Maven’

I use Maven Bundle plugin a lot since our projects are OSGi based. Basic idea I had of this plugin is that this plugin makes an OSGi bundle out of a normal jar (basically by augmenting the META-INF file) if we do declare exported and private package information correctly in it’s configuration section in the POM declaration. Normal procedure followed would be to copy the configuration from an existing POM and tweaking it according to the current project requirements. My knowledge about it was just about it until recently. It was when I bumped up on a strange issue one day I was forced to read more on the subject and fortunately solution was not that far away with the amount of comprehensive documentation and FAQ section found at plugin’s site [1].

So why am I making a blog out of this if all what you want to know is well documented somewhere else?

Well, mostly to document some points which do matter, in a concise point form as a future self reference rather than going through the lengthy documentation every time when my memory fails me. (Not a rare occurance I would say.. :)).

So here goes.. My points with bullets.. :).

  • <Export-Package> will copy the packages to the bundle and export them in the MANIFEST while <Private-Package> will copy the packages to the bundle even-though they will not be exported.
  •  If you want a class to be included in the bundle make sure the package that it lives in is present in either of these instructions or otherwise it will not get included in the bundle.
  •  If <Export-Package> and <Private-Package> overlaps <Export-Package> takes precedence.
  • Using negation “!” in <Export-Package> declaration will result in package being not included bundle and not exported as well.
  • If a negation following an non-negated package declaration overlaps with the non-negated package declaration, the negated package pattern will not take effect. Always put negations first in  <Export-Package> instruction to avoid these kind of issues.
  •  Plugin generates the Import-Package bundle manifest header based on the Java imports present in the classes of the bundle so generally it’s not needed to specify it explicitly.
  • If a referenced packages do not need to be available for at runtime for bundle to perform its intended task (e.g: only a test scoped class using the package which is only needed during test runs..) use negation inside not to import it.
  • If you need to import a package not referenced by any class in bundle use resolution:=optional directive after the package name as follows.

org.external.package;resolution:=optional

   The bundle would resolve even if the package is not present at runtime.

  • Use to import a dynamically loaded class (e.g: Using Class.forName()) given that it’s exported in originating bundle. Generally using “*” wild-card would do, since it will enable loading any dynamically loaded class in other bundles given that the package it lives in has been exported by those bundles.

So that’s about it for my notes. If you want a good tutorial have a look at [2] as well. By the way in case you are wondering about the issue I had, the second point sums it up pretty nice. :).

[1] http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html

[2] http://wso2.org/library/tutorials/develop-osgi-bundles-using-maven-bundle-plugin

Advertisements

Read Full Post »

A Maven Bug

If you encounter following during a Maven build,

 

java.lang.ArrayIndexOutOfBoundsException: 0 at      org.apache.felix.scrplugin.tags.JavaClassDescriptorManager.getSourceDescriptions(JavaClassDescriptorManager.java:344) at  org.apache.felix.scrplugin.SCRDescriptorMojo.execute(SCRDescriptorMojo.java:110) at  org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at  org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at  org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at  org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at  org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at  org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at  org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at  org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)

 

check whether if there are any empty classes (totally commented out classes) lying around inside the sources. If so remove them and it would most probably build fine.

 

Read Full Post »