I would love to see robust OSGi support merged into Titan. I'm not ready to force users to use OSGi to resolve dependency conflicts yet, but the option to use it would be great.
Build Titan OSGi bundles
Titan (Cassandra) currently is (nigh?) impossible to deploy in an OSGi container. It would be great if this could be enhanced.
- the Titan jars should be built as proper OSGi bundles
- The Titan persistence modules must be visible from titan-core in order for the call to Class.forName() in
com.thinkaurelius.titan.util.system.ConfigurationUtil to work.
- reflections 0.9.9-RC1 does not work in OSGi environments because it relies on URLClassLoader; it would have to be replaced
- the dependency to commons-configuration should be upgraded to a version >= 1.8; the currently used version 1.6 has a broken MANIFEST; see this issue
- titan-cassandra.jar contains a package duplicated from the cassandra-all jar; this package must not be exported (and maybe should not be there in the first place?)
- titan-core and cassandra-all use Guava 15, whilst the astyanax driver (OSGi bundles) and tinkerpop frames depend on 14.0.1; which would be OK if all jars were proper bundles, but with the current mix it results in multiple dependency chains from titan-cassandra to guava
- For Karaf users it would be great if there was a feature repository available to easily deploy the different Titan modules (and their dependencies)
- weixin_39621185 4月前点赞 评论 复制链接分享
Providing OSGi bundles would not force anyone to use OSGi. But it would make the live of those easier who work with OSGi environments. Or maybe I do not correctly understand your comment about forcing OSGi use?点赞 评论 复制链接分享
- weixin_39621185 4月前
OSGi support would be nice. I'll gladly accept changes towards better behavior inside an OSGi container insofar as those changes are unobtrusive, i.e. do not interfere with noncontainerized execution. Put another way: I'm not ready to require an OSGi container to run Titan.
I would be surprised if the changes listed in the report are the only ones required to make all Titan modules well-behaved under OSGi. I suspect this would be a substantial bit of work and testing. I would love to be wrong about that though.
By the way, you may be aware, but Guava is far from an isolated example. Titan's dependency tree contains dozens of artifacts, some several levels of transitive dependency deep, for which there are multiple paths specifying different versions. Hence the long dependencyManagement section in Titan's top-level pom and the maven-enforcer-plugin dependencyConvergence rule (and "shaded" classfiles).点赞 评论 复制链接分享
Yeah, the list in the ticket surely is not exhaustive. It is just items that I encountered before I gave up... The total amount of work is mostly dependent on how many of your direct and indirect runtime dependencies are already built as OSGi bundles. The problem of "same dependency in multiple versions" should actually be easier to deal with in an OSGi environment. Once they are all OSGi bundles that is. The problem with Guava (and probably others) is that they are not OSGi bundles. So when the container loads artifacts that are plain JARs it has to convert them to bundles on the fly. But it has no version information for the APIs exposed by the artifact. This then leads to ambiguous paths that the container cannot resolve. For non-OSGi users nothing changes what so ever. OSGi bundles are still plain JARs with a bunch of extra meta-data in their MANIFEST file that gets ignored by non-OSGi runtimes. OSGi or not, the dependency management system would still be Maven (or whatever else you choose to do the job). Building bundles requires a one-time(?) effort to set up the maven-bundle-plugin. Providing a Karaf feature repository is a one-time(?) effort to set up the karaf-maven-plugin. (Disclaimer: I am be no means an OSGi expert. I just happen to work on a project right now that attempts to employ an OSGi runtime.)点赞 评论 复制链接分享
- weixin_39680121 4月前
I'm not using Titan yet, but I planned to use Tinkerpop3 and pointed me to this direction.
Just for the record, the official Guava JAR has been a valid OSGi bundle for some time now (years afair), precisely because it's almost painless for Guava developers (who are not OSGi users) to maintain.
As it's been pointed by already, making any Java project consumable in OSGi does not imply forcing users to use OSGi. However, the developers have to be a little more careful because when it comes to dynamically loading classes, OSGi is not as tolerant as plain Java where there is no classloader isolation. Because of this, a properly OSGified project will delegate its classloading to OSGi, whereas the plain Java version can continue to rely on its loadClass() mechanics, preferably in an artifact that is distributed only in the "plain Java distribution" since it's useless in OSGi environments.
When it comes to dependencies (and transitive dependencies), there are a few choices: - if they're OSGi-ready, consume them as external dependencies - if they're not, either make them OSGi-ready (preferably upstream, like we're trying to do with Titan & Tinkerpop3, rather than maintaining a fork), or embed the dependencies within the bundle where there will be no classloading issue. Obviously this is an inferior solution, since it implies creating an "über bundle" that is much fatter, even when some features might be optional.
Once Titan/Tinkerpop3 can be made OSGi-ready, there's nothing left for the development team except a few gotchas to keep in mind. Mostly, keeping classloading separate and avoiding breaking the build, but an automatic test can test if the bundle is remains valid pretty easily.点赞 评论 复制链接分享
- weixin_39899776 4月前
Realistically, is this something anyone is going to do or can we just close this ? I haven't seen a single request for OSGi with a single one of my use cases. If someone wants it that badly, can we ask them to show up with a sample build ?点赞 评论 复制链接分享
Bummer.点赞 评论 复制链接分享