Hi David, Bundle-ClassPath is an osgi header that specifies the internal class path structure of a bundle. -conditionalpackage is a bnd instruction that pulls in specific packages that are actually used from dependencies.
I was suggesting including all of neo4j in the bundle using the -includeresource bnd instruction and setting the Bundle-ClassPath header by hand to include the normal bundle contents under . and also all the neo4j jars copied in using the -includeresource instruction. If you wanted to use this idea in your bundle without distributing neo4j at all, you could include the Bundle-ClassPath header and ask users to run a zip command to add the neo4j jars themselves. I don’t remember what you may have to do to get bnd to not generate Import-Package headers for the packages in the included jars. My idea with this over -conditionalpackage is that you are using the neo4j jars completely unmodified, but contained in an appropriate osgi environment (completely hidden inside the bundle). -conditionalpackage is a considerably more sophisticated approach, if you are comfortable with the licensing implications. thanks david jencks > On Sep 9, 2018, at 4:35 PM, David Leangen <[email protected]> wrote: > > > Thanks for this info. > > Could you please explain more what you mean by: > >> uses bundle-classpath > > > Is this something different from Conditional-Package? > > > Cheers, > =David > > >> On Sep 10, 2018, at 6:31, David Jencks <[email protected]> wrote: >> >> 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... >>> >> >
