felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Ch-ch-ch-changes...
Date Thu, 02 Nov 2006 22:36:30 GMT
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

View raw message