2009/3/12 Martin Krasser <[email protected]> > Hi, > > I'm writing this to both mailing lists because I'm not sure whether my > problem is releated to Groovy/gmaven-plugin or the maven-bundle-plugin from > the Apache Felix project. > > I'm using the maven-bundle-plugin to generate OSGI MANIFEST.MF headers for > my Groovy projects. The Import-Package entries are created as expected when > the gmaven-plugin 1.0-rc-3 is used but for some cases it doesn't work when > the gmaven-plugin 1.0-rc-5 (with Groovy 1.6) is used. > > A simple example project that demonstates the problem can be downloaded > from http://repo.openehealth.org/sites/tmp/groovy-bundle.zip . It's a > Maven 2 project. Running 'mvn install' creates a MANIFEST.MF in the > target/classes/META-INF folder. > > In this example I'm using this Groovy class > > import javax.xml.transform.TransformerFactory > class Sample { > void activate() { > TransformerFactory.newInstance() > } > } > > Compiling the code with gmaven-plugin 1.0-rc-3 and running the > maven-bundle-plugin creates a > > javax.xml.transform > > entry in the Import-Package header (as expected). When using gmaven-plugin > 1.0-rc-5 this entry is not created. I tried with both versions, 1.4.3 and > 2.0.0, of the maven-bundle-plugin - no success in this case. > > Any ideas? >
Hi Martin, looks like the generated bytecode changes from 1.0-rc-3 to 1.0-rc-5 if I build with gmaven-plugin 1.0-rc-3 and run "javap -v target/classes/dev/sanbox/issues/groovy/bundle/Sample" one of the items I see when grepping for "javax" is: static java.lang.Class class$javax$xml$transform$TransformerFactory; when I build with gmaven-plugin 1.0-rc-5 no such entry appears I only see string constants that refer to the TransformerFactory and no actual type constants so because the maven-bundle-plugin uses bytecode to work out what packages you need to import at runtime, when you build with 1.0-rc-5 there isn't a type reference to the "javax.xml.transform" package in the compiled code and so it doesn't add any import note this can also happen with code that uses "Class.forName()" because there's no guaranteed way to tell from the compiled code which strings refer to packages and classes, and which ones just happen to look like they do. and even if you did have a way to heuristically identity strings as potential packages you'd still miss cases where a class name was constructed dynamically at runtime based on XML/properties unfortunately in these situations you have to manually add the import by tacking it onto the Import-Package instruction, like so: <Import-Package>javax.xml.transform,*</Import-Package> sometime in the future it might be possible to plug processors into the bundleplugin to feed in additional information (like script details or Spring XML config for example) - I know Peter Kriens was working on this for the BND tool, but don't know the current status HTH > Thanks in advance for your help, > Martin > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Cheers, Stuart
