Problem resolving a groovy.* class in bundle

[constv]

As I am repackaging and porting a legacy application to OSGi, I have come across the following issue. There is a Java class whose implementation uses a Groovy class. That Java class is defined in bundle A and its instance is exported as an OSGi service.  Another bundle (B) successfully picks up the reference to that bean and attempts to use it at runtime. However, as soon as the bean calls a method on a groovy class, the exception is thrown:

java.lang.NoClassDefFoundError: groovy.xml.MarkupBuilder

I have Groovy Runtime (1.8.6) running/Active in Karaf. "packages" on that bundle shows that groovy.xml is present. Both my bundles define the necessary Groovy dependencies (as "provided", but I have also tried including the jar inside the bundle as well - although I know it should not be necessary.)  I have tried explicitly importing groovy* packages by using the Maven bnd plugin's

Could anyone suggest what actually may be missing, and why that is happening?  I have wasted a whole day trying to solve this, and can't figure it out.

Thanks for your help,

Constantine

[davsclaus]

How do you package your bundles? Do you use FAB or the Maven bundle plugin etc?

If you type: headers nnn in the shell, where nn is the bundle id, then you can see the packages that bundle import|export etc. You would need to have the groovy packages as imports on the bundle that calls the service (B). So the groovy classes is visible on the classpath.

[constv]

I am using the bnd plugin, and yes, I had made sure - as I noted in the original post - that running the "packages" command on the bundle confirms that all the necessary groovy.* packages are present.

I actually got it to work by adding the following directive to the Maven "bnd" plugin instructions:

<DynamicImport-Package>*</DynamicImport-Package>

I found that suggestion buried in some year-plus-old forum - as a work-around for a known issue in camel-groovy in OSGi. I am using camel-groovy v2.10.2 in Karaf, and apparently the issue still exists.  It really needs to be documented better because I'm sure people waste countless hours on stuff like that.