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.
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.