Oct 7th, 2009, 07:32 AM
Project Configuration Advice
Pardon me if I'm asking a question that has an obvious answer. I'm still trying to swallow the mountain of not just information but options in how to accomplish my goals here, and want to see what has worked best for others.
We are in the process of transitioning non-OSGi/non-Spring DM web application projects into a collection of bundles for deployment in Spring dm Server. These old projects were built using maven integrated with eclipse, and what was working nicely then which we'd like to preserve is that the maven was the primary driver of the build - we used maven to build the production artifacts but there was nothing else you had to do in eclipse (other than project references) to get the eclipse environment working the same way.
We're now using STS 2.1.0 SR01 and the dm Server 1.0.2.SR02.
I've found that I can use eclipse in roughly the same way with my projects if I add the OSGi bundle dependency nature, put a TEMPLATE.MF file at the root of my project and let the MANIFEST.MF file be generated (by eclipse?) and updated automatically. I've had to do nothing special in my poms aside from referencing osgi-ified dependencies rather than the old legacy ones when those existed.
Now here's what I've not yet figured out, and would appreciate some direction:
- If I run the maven build from the command line, I won't get the updated manifest.mf file if anything changed. I'm assuming a plugin is required here, but which would work best without interfering with eclipse? There seem to be several options: felix bnd, bundlor, a few others I saw...
- If a dependency declared in the pom is not an osgi bundle, ideally this would be embedded in my output automatically and the manifest.mf's bundle classpath updated automatically. I've not seen anyone talk about this being possible. Is it?
Appreciate any hints!
Oct 7th, 2009, 12:15 PM
I'm not saying this is the best way to do things, but this is what works for us:
1) We use Bundlor in our Maven POMs to generate the manifest.mf. We used to use the Spring tools in Eclipse to generate the manifest, but of course when we got to the point of doing command-line builds, it was important to ensure that the manifest was always up to date, so we added Bundlor. We then removed our manifest from the repository and added it as an ignored file, so it isn't checked into SVN. You can setup Bundlor to copy the manifest to a particular directory as well as embed it in the bundle, which is what we have done.
With our development process, we typically will checkout all the projects in the morning from the command line using svn, then we do a maven build from the command line. Our projects in Eclipse are imported directly from our source tree that we checked out, so it's just a matter of refreshing the projects in the workspace after the maven build is done, which will pick up the generated manifests. During daily development, if there is a simple change in 1 or 2 bundles, I usually just update the manifest manually using the Spring tools in Eclipse (right click on the template.mf, Spring Tools, Generate manifest.mf), otherwise I run another maven build and refresh the Eclipse workspace.
The reason we used Bundlor is because that is the same tool used inside STS (although an older version), so both manual generation inside STS and command-line builds use the same template.mf file.
2) For embedded jars, we copy them to the root of the "resources" directory in Eclipse (/src/main/resources) and then manually add them to the bundle classpath in template.mf. I'm not aware of a way for Bundlor to detect embedded jars and do this for you. Not saying it can't be done, I'm just not aware of how or even if it can do it.
I've also found that embedded jars can require a lot of trial and error manual editing of the template.mf. We have a bundle that embeds Jackrabbit, and I had to do quite a bit of manual editing of template.mf to get things working, mainly because Jackrabbit loads a lot of classes reflectively based on settings in configuration files. Also, if you export any of the packages contained in your embedded jars, you very well may have to add those exports manually to template.mf. It's kind of a pain to get setup initially, but once you get your template right, it's pretty low maintenance since these tend to be library jars that aren't changing in response to your day to day development. Fortunately, we rarely have to embed jars in our bundles. Jackrabbit was a special case, and it's the only one we're doing it for, although it appears I'll have to do the same thing for Drools.
Last edited by txmikester; Oct 7th, 2009 at 02:05 PM.
Oct 7th, 2009, 01:35 PM
Thanks - this is helpful to get some reports of real experience. Anyone else doing anything different?
Also, for those following this thread, I posted a related question @ http://forum.springsource.org/showth...729#post263729