As a follow up, one more change I forgot to mention...
As a result of how the new plugin works, I changed the way that the
"main" subproject works. Previously, the "main" project created its own
JAR file that contained only the Felix launcher class and then copied
the framework and osgi core JARs into a lib/ directory.
With the new plugin, I modified "main" to copy all of the JARs into a
single JAR file. The benefit of this approach is that we are assured of
getting our correct dependencies at launch...the old approach was
problematic because it required that framework.jar was on the class path
before osgi.jar, because framework.jar overrides some classes in
osgi.jar. Now we don't have that problem...
That's all for now.
-> richard
Richard S. Hall wrote:
Ok, I committed the new Maven Bundle Plugin. I created some docs for
the new plugin here:
http://cwiki.apache.org/FELIX/bundle-plugin-for-maven-bnd.html
I think the plugin is in pretty good shape now. In my opinion, we
should probably replace the old plugin with this new one, but we don't
need to make that decision right now since we have both in the repo.
As part of committing the new plugin, I updated several of the
subprojects to use the new plugin and everything looks pretty good,
except...
The catch is that Maven has a bug that appears when you have multiple
packaging plugins in the same project. We saw this bug first appear
with iPOJO, which has its own packaging plugin. The symptom of this
bug is that the generated JAR files do not have a .jar suffix, but
instead are named after the packaging type. We were able to avoid this
bug by putting iPOJO at the end of our modules, because we don't have
any modules in the repo that use the iPOJO plugin. However, with this
new plugin, we have bundles trying to use both the old and the new
plugins at the same time and this made the problem reappear. I could
not find any way around it from within Maven...thus, I had to resort
to extreme measures.
What I did was split out top-level pom.xml file into two files, one
containing subprojects that use the new plugin and those using the old
plugin. I then created an Ant build.xml file that will build both
files. You can do "ant clean", "ant install", or just "ant" to do
"clean install". Until Maven fixes this bug, I don't see another way
around it...unless everyone does like the new plugin better, then we
can convert all subprojects to the new plugin and go back to one
pom.xml file.
Otherwise, I am very pleased with the new plugin...
-> richard
