IANAL and I really can’t understand the GPLv3. rebundling or wrapping neo4j jars definitely modifies them. I’m not sure if having karaf or maven do this on the user’s system compared with distributing such already modified jars makes a difference to the license implications.
If you make a jar that embeds the neo4j jars (as jars) and uses bundle-classpath you are not modifying the neo4j jars at all. Doing this, you can hide neo4j from the outside of your bundle and provide an API that does exactly what your program needs. Peter Kriens highly recommends doing this with external dependencies that are not designed from the start for OSGI. To repeat, I don’t understand GPLv3. If it prevents you from distributing a bundle with your code, also embedding the neo4j jars, I don’t see how it could prevent you from distributing your code plus a script that constructs such a bundle; such a script would just be something that puts neo4j jars in a particular place in a production system. David Jencks > On Sep 9, 2018, at 12:35 PM, Steinar Bang <[email protected]> wrote: > >>>>>> Jean-Baptiste Onofré <[email protected]>: > >> why you don't just put this as private package. You will avoid class >> loading issue this way. > >> In OSGi, not all is necessary an import. It could be a private package >> and/or embed dependency. It means the packages are embedded in the >> bundle. The bundle is "fat" but you avoid classloading issue this way, >> especially when the dependency is not designed for OSGi. > > Um... not sure what you mean...? Do you mean rebundling Neo4J before > pulling it into karaf? Either individually (*lots* of work, probably), > or as a fat jar (less work if the maven dependencies of the top jar can > be made to do the trick). > >> Unfortunately, I wanted to create neo4j bundle at ServiceMix, but it's >> not possible due to neo4j license. > > Yeah, the licensing was why I didn't rebundle with maven in the first > place. I hoped the wrap protocol could do the trick... >
