I don't have much experience using OSGi, but maybe someone using it might chime in. Given my understanding of OSGi, you are doing things correctly.
Our goal with OSGi is to simply enable the ModeShape's JAR files to be used within an OSGi environment (that is, making them OSGi bundles), saving our users from having to manually create OSGi bundles for them. But because we don't include third-party dependencies in our JARs/bundles, you must still provide them, either by finding the appropriate OSGi bundle or building bundles for those libraries that don't offer OSGi bundles (like Lucene). In the latter case, I'd suggest asking those projects to start producing OSGi-enabled JARs.
Unfortunately, the end result still means using ModeShape within an OSGi container is still not terribly easy. Sorry I don't have a better answer. Please let us know if we can improve our support for OSGi!
As far as Google Collections, we can't change the fact that our released versions depend on Google Collections. It does sound like Guava can be used in place of Google Collections, and that may work for you. Feel free to log a JIRA issue requesting that we replace our Google Collections library with the newer Guava library.
Thanks a lot Randall,
At the moment I got by putting everything (ModeShape and all its dependencies) into one bundle; in this way, the dependencies are satisfied.
This has been done creating an independent maven project and configuring the bundle plugin to export the packages my application bundle depends on.
Easier to do than to describe, maybe
I think that this might not be the best solution ever, but in the meantime if it works, it will be ok for us.
Thanks for helping me to get out of this hell
Glad you got something to work. I still think/hope there's a way to do this without users having to create their own bundles, but I'm unsure what that is.
Keep us posted on your progress!
I did some work within Brix  to get Jackrabbit working in an OSGi environment. It was kind of a pain, I had to make a bundle as Alessandro described, although I might have done it slightly differently using Embed-Dependency. After that, I exported the interfaces that I needed and ended up with a much larger artifact that had Jackrabbit in it.
In order to keep things sane, I did not export anything from org.apache.jackrabbit.*, just the JCR interfaces. Then, by registering the Jackrabbit implementation of those interfaces, they could be discovered by other services in the container.
I haven't looked around much within the forum or source code to see if this has been taken care of in Modeshape, but myself and an associate are very interested in doing much more with it and would be happy to contribute patches if they are relevant.
Kind regards, Brian
First things first ... ModeShape no longer depends on Google Collections, so that earlier problem shouldn't be a problem anymore.
Secondly, we build two kinds of JARs: those for Maven that don't include any dependencies, and those that can be downloaded and used for traditional "classpath" applications. The JAR of JARs is available for the 2.6.0.Beta2 release here and described here and contains a bunch of "-with-dependencies.jar" files that contain the required dependencies and should still be valid OSGi bundles. We'd be very interested in hearing whether this works for you and whether we need to improve how this works.
Any suggestions and/or contributions would be very much welcomed, whether it's just regarding OSGi support or any other features, bug fixes, or improvements. Contributing is pretty easy ... just fork our GitHub repository, create a branch for each issue you're working on, and create a pull-request on GitHub (see ModeShape Development Workflow for the full details). ModeShape does require a Contributor License Agreement for non-trivial submissions (see http://cla.jboss.org for details and for signing).
What do you think?