Also, in the past, we have overcome issues like this by providing our custom bundles for the Karaf features [1] or have repackaged the conflicting libraries using the maven-shade-plugin. It is not an ideal solution and the last option, but it is worth knowing things like these have been done in the past.
I'd contact those projects and file an issue in their corresponding issue tracker so they can provide proper OSGi compat. [1[ https://github.com/jclouds/jclouds-karaf/tree/master/bundles On Thu, 14 Feb 2019 at 11:57, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi Paul, > > I will take a look, I think I changed in SMX bundles, but we embed the > package in jclouds. > > Regards > JB > > On 14/02/2019 11:34, Paul Campbell wrote: > > Hi, > > > > I've been working on the Apache Brooklyn project upgrading various > > dependencies. I ran into an issue with sshj and its dependency upon > > eddsa and was told that you might be interested in what I discovered. > > > > Currently jclouds-sshj depends on sshj v0.20.0, which depends on > > net.i2p.crypto:eddsa:0.1.0. > > > > In the constructor for the sshj class > > com.hierynomus.sshj.signature.Ed25519PublicKey it has two calls to > > getCurve() methods, each of which return an instance of > > net.i2p.crypto.eddsa.math.Curve. > > > > Unfortunately, when eddsa added the maven-bundle-plugin to their pom, > > they didn't export the net.i2p.crypto.eddsa.math package, indeed they > > actually marked it as Private-Package in its pom.xml. > > > > Given this is all in place now, I'm not sure how this is working under > > OSGi. > > > > From sshj v0.23.0 onwards, it depends on eddsa 0.2.0. > > > > This particular combination is where things stop working under OSGi and > > we end up with a NoClassDefFoundError for the Curve class. > > > > Which confuses me as I can't see what has changed to cause this. > > > > > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
