Thanks, Rick, I got this issue too while trying to remove the classloader plugins :-) I guess that only those *-builder will need to import those xmlbeans gernated classes, shall we use a tool to scan and generate the whole package list, then add them to those pom files. I remembered that long ago, there is a discussion about removing xmlbeans from Geronimo, and use jaxb to parse and generate the plan file, Maybe we could do it in 3.0.
2009/11/3 Rick McGuire <[email protected]> > I've been wrestling with some build problems involving xbeans and bundles > since the middle of last week, and I've finally gotten the specific error I > was working on to go away. I'm not entirely happy with what I needed to do > to fix this, so I think this needs a little discussion. First, some > specifics on what I've found. > > 1) The problem. This problem was showing up when trying to build the > system-database plugin. It was starting the connector-deployer-1_6 plugin > and getting a NullPointerException inside the xmlbeans runtime after calling > getEnvironment() on the ConnectorDocument class. This was happening because > the xmlbeans runtime was unable to locate the type information for the > environment property of the document. > > 2) The cause. This situation was occurring because the ConnectorDocument > class uses property types defined in the geronimo-system-builder module. At > first, I thought this was due to some missing imports for the > org.osgi.geronimo.deployment.xbeans.impl and > org.osgi.geronimo.deployment.javabean.xbeans.impl packages. I spent a > couple days trying to get these imports correctly defined, but adding these > did not clear up the NullPointerException on the getEnvironment() call. > 3) Finally, after poking around in xmlbeans a little, I figured out the > issue was not the implementation classes, but rather the .xsb files. The > directories where these are contained also needed to be exported by the > defining bundles and also imported by the using bundles. > Item 3 is where the problems come in. Because of the way xmlbeans > generates the type information, there are lots of packages that need to be > exported and imported to make things work. Importing was fairly easy, since > the bnd tool allows wildcards. Importing is another matter entirely. Since > the referencing bundles don't contain any code references to these packages, > the bnd tool is unable to generate this directly. Any since there are a lot > of directories involved that have very cryptic names, it really doesn't look > practical to hand generate each of these either. > > A solution that did work is to use Require-Bundle to have all of these > packages get imported by the using bundle at runtime. I'm not terribly > happy with having to resort to this, but bnd doesn't have a capability of > doing the static equivalent of a Require-Bundle when generating the > manifest. The combination of export all of those packages and using > Require-Bundle finally made the NullPointerException go away. > > In the course of fixing this, I also added a couple of enhancements to the > car-maven-plugin to allow the manifest to be augmented by additional > Import-Package and Require-Bundle information. This looks like it is going > to be additional metadata that we'll require in some of these dynamic > classloading situations. > > I'll update the wiki with the workarounds I've found for this problem once > we're comfortable with the approach needed to fix this. > > Rick > -- Ivan
