SourceForge.net Logo
Main Overview Wiki Issues Forum Build Fisheye
Issue Details (XML | Word | Printable)

Key: CMP-691
Type: Improvement Improvement
Status: Open Open
Priority: Minor Minor
Assignee: Shay Banon
Reporter: Craig Walls
Votes: 2
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
Compass

Make Compass OSGi-ready

Created: 04/Aug/08 12:31 PM   Updated: 26/Aug/10 06:32 AM
Component/s: Compass::Core
Affects Version/s: 2.0.1
Fix Version/s: None

File Attachments: 1. Text File MANIFEST.MF (57 kB)
2. File osgi.bnd (2 kB)
3. File osgi.bnd (1 kB)
4. File osgi.bnd (0.2 kB)



 Description  « Hide
Take steps to provide a proper OSGi-ready manifest in the Compass JAR.

Some specific gotchas to look out for:

  • Split packages with Lucene - The best way to deal with this is to embed Lucene within the Compass bundle and use the Bundle-ClassPath: header to find the Lucene packages. I'd also be inclined to try splitting the Compass JAR into 2 or more JAR files...with one of them being the Lucene-specific packages. That way the Lucene goofyness is confined to that JAR/bundle and not part of the core bundle.
  • Proper import of packages that Compass depends on dynamically. If you create the manifest manually, this probably won't be a problem, because you'll know what to import. If you use BND to generate the manifest, however, anything that is loaded with Class.forName() won't be imported by Compass. For those, you should include DynamicImport-Package headers.


 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Shay Banon added a comment - 04/Aug/08 01:27 PM
I create the manifest manually. I am by no means an OSGi expert, can you please post what needs to be in the manifest of Compass in order to enable it?

Regarding embedding Lucene jars within Compass, this needs some built work (which I will do). It will probably be available as another type of distribution option.


Craig Walls added a comment - 04/Aug/08 01:42 PM
Absolutely...I'm planning on posting the MANIFEST.MF that BND created for me (and that seems to work at least for the stuff I'm doing). It's a bit wordy, as BND tends to import EVERYTHING that it thinks it needs and tends to export EVERYTHING in the JAR. If there are any classes/interfaces/enums/etc that are part of the internal API, then perhaps those packages can be removed from the export.

I'm away from the machine that has that manifest on it, but I'll attach it to this issue when I get a chance.


Craig Walls added a comment - 05/Aug/08 06:57 AM
Here's the MANIFEST.MF that BND (via Pax-Construct) created for me. It seems to work, but I'm sure that it's non-optimal.

Craig Walls added a comment - 05/Aug/08 06:59 AM
For the sake of completeness, here's the BND instruction file used to create the MANIFEST.MF.

Craig Walls added a comment - 05/Aug/08 07:01 AM
Note that the DynamicImport-Package is applied in the bundles that depend on Compass (because it's in those bundles' class space that the dynamic loading happens), so those aren't shown here.

Piotr Zieleziński added a comment - 13/Aug/08 03:06 AM
There is also a small problem with class: org.springframework.transaction.support.ExistingSpringTxCompassHelper provided with Compass in OSGi env.
I have exported it to a frgment bundle and attached it as a fragment to org.springframework.bundle.spring.tx

Shay Banon added a comment - 13/Aug/08 12:06 PM
I have actually remove the spring thingy from 2.1 since it is not used anymore. Regarding the OSGi fixes, I am also working with Spring to make it OSGi enabled, I will merge both manifests once I get that other one from Spring.

Anders Storsveen added a comment - 26/Aug/10 05:15 AM
I've been trying to get this to work by myself, and came over this page. doing import-package: *;resolution:=optional is really bad. That removes all the good parts of osgi. The goal should be to import-package all packages that are needed, and then add resolution:=optional to only those who really are optional (i.e. runtime). Also it should Export-Package only the packages needed to be imported by other code/bundles and the rest should be set in private-package. There is a loooot of packages in this file, with a lot of imports in them, but I'm going to try to get it to work. I'll report back with an osgi.bnd file if i'm successfull. Keep in mind though, I have no idea what actually is optional and what isn't, so I'm going by the referenced libraries that eclipse pulls in.

Anders Storsveen added a comment - 26/Aug/10 06:08 AM
Given this list of exports, which seems to satisfy most all my constraints, the attached osgi.bnd file seems to work. There should still be a split of the org.apahce.lucene stuff I think though and there might be a lot of packages that needs to be set to Private-Packages and lots of more imports to be set optional.

Anders Storsveen added a comment - 26/Aug/10 06:32 AM
Re-upload after I found out that doing export-package: package.name* actually doesn't include package.name, only package.name.*.

For someone with more time on their hands, they can also include all the spring, jboss gps and such stuff. and then set resolution:=optional on all the imports it pulls in.