Yes, right. Neo4j right now is only using Java Service Loader. Reason for that is that, as stated in the other thread, it's very hard to decide on the granularity of exposed services without spamming the Service Registry with Neo4j internal stuff. If we register every index provider and kernel extension, or really any code that is extensible and could live in its own bundle/jar, then we would run the danger of having 150 registered neo4j internal services and bundles in the whiteboard-model of OSGi (e.g. Virgo or Eclipse). That is not good behavior IMHO.
Also, that would trigger people to try and have more coarse-grained bundles etc etc. So, it's not clear how OSGi at the database level would add much value over a default-superbundle that corresponds to Neo4j Community, and a recipe to build your own bundles as part of your custom OSGi system. Sorry for being negative here, but we have talked a lot about this, and I as an OSGi fanboy have to admit that this makes a lot of sense, considering that I have been down the path of fine-grained components in Maven before in several OPS4J project build systems like Metro (http://www.dpml.net/metro/concepts/index.html) that exploded into over 150 components just to build the core system :) Cheers, /peter neubauer GTalk: neubauer.peter Skype peter.neubauer Phone +46 704 106975 LinkedIn http://www.linkedin.com/in/neubauer Twitter http://twitter.com/peterneubauer http://www.neo4j.org - Your high performance graph database. http://startupbootcamp.org/ - Öresund - Innovation happens HERE. http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party. On Wed, Jul 20, 2011 at 10:39 PM, Alexander Smirnov <[email protected]> wrote: > Just curious - as I traced down OSGI service loading from the neo4j > Service class it commented out, so the only Java META-INF/services > used in any environment. May be that's the case ? > > On Wed, Jul 20, 2011 at 4:55 AM, Jörg Richter <[email protected]> wrote: >> >> Thanks for replies! >> >> Yes, the super bundle approach (putting *all* neo modules and *all* their >> dependencies in one bundle) works in principle. But to be a deployable >> solution ... >> 1) it must exist in the Maven repo and be on a par with the Neo4j release >> 2) A configuration mechanism is required to choose the modules actually >> needed >> >> To abandon the super bundle approach and as long as the original problem >> (Java Service Loader and OSGi) is not solved: how about bringing back the >> old-style (serviceloader-less) indexing API as an *alternate* entry point? >> >> This would allow thousands of OSGi users to use Neo4j > 1.2 and they would >> love it. >> >> Cheers, >> Jörg >> >> >> >> On Jul 20, 2011, at 9:20, Peter Neubauer wrote: >> >>> Could you please try the OSGi neo4j super bundle built in github / neo4j / >>> Neo4j - osgi / bundle? >>> >>> Fine grained bundle deployment interferes with the java service loader which >>> only looks in its own classpath. >> >> _______________________________________________ >> Neo4j mailing list >> [email protected] >> https://lists.neo4j.org/mailman/listinfo/user >> > > > > -- > _________________ > entia non sunt multiplicanda praeter necessitatem, > (entities should not be multiplied beyond necessity.) > _______________________________________________ > Neo4j mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
