David Jencks wrote:
I'm seeing a lot of warnings like this:
[WARNING] Warning building bundle
org.apache.geronimo.modules:geronimo-naming-builder:bundle:3.0-SNAPSHOT
: Split package
schemaorg_apache_xmlbeans/javaname/org/apache/xmlbeans/impl/xb/xsdschema/Attribute
Use directive -split-package:=(merge-first|merge-last|error|first) on
Export/Private Package instruction to get rid of this warning
Package found in [Jar:geronimo-j2ee-builder,
Jar:org.apache.servicemix.bundles.xmlbeans, Jar:geronimo-service-builder]
Reference from
/Users/david/.m2/repository/org/apache/geronimo/framework/geronimo-service-builder/3.0-SNAPSHOT/geronimo-service-builder-3.0-SNAPSHOT.jar
Classpath [Jar:., Jar:geronimo-j2ee-builder,
Jar:geronimo-j2ee-schema, Jar:geronimo-deployment,
Jar:geronimo-system, Jar:geronimo-cli, Jar:geronimo-main,
Jar:commons-cli, Jar:geronimo-common, Jar:geronimo-kernel,
Jar:org.osgi.core, Jar:pax-logging-api, Jar:asm, Jar:asm-commons,
Jar:org.apache.servicemix.bundles.cglib, Jar:xbean-reflect,
Jar:org.apache.servicemix.bundles.xstream,
Jar:org.apache.servicemix.bundles.xpp3, Jar:geronimo-crypto,
Jar:org.apache.servicemix.bundles.commons-jexl,
Jar:org.apache.servicemix.bundles.commons-lang,
Jar:org.apache.servicemix.specs.jaxb-api-2.1,
Jar:org.apache.servicemix.specs.stax-api-1.0,
Jar:org.apache.servicemix.bundles.jaxb-impl,
Jar:org.apache.servicemix.specs.activation-api-1.1,
Jar:org.apache.servicemix.bundles.woodstox,
Jar:org.apache.servicemix.bundles.xmlbeans,
Jar:org.apache.servicemix.bundles.xmlresolver,
Jar:geronimo-schema-jee_5, Jar:geronimo-schema-j2ee_1.4,
Jar:geronimo-service-builder,
Jar:geronimo-javaee-deployment_1.1MR3_spec, Jar:geronimo-j2ee,
Jar:geronimo-management, Jar:geronimo-j2ee-management_1.1_spec,
Jar:geronimo-deploy-config, Jar:geronimo-annotation_1.0_spec,
Jar:geronimo-ejb_3.1_spec, Jar:geronimo-jpa_2.0_spec,
Jar:geronimo-servlet_3.0_spec, Jar:xbean-finder, Jar:geronimo-naming,
Jar:xbean-naming, Jar:geronimo-jta_1.1_spec, Jar:geronimo-el_1.0_spec,
Jar:geronimo-interceptor_3.0_spec,
Jar:geronimo-j2ee-connector_1.6_spec, Jar:geronimo-jacc_1.1_spec,
Jar:geronimo-jaspic_1.0_spec, Jar:geronimo-javamail_1.4_mail,
Jar:geronimo-jaxrpc_1.1_spec, Jar:geronimo-jaxr_1.0_spec,
Jar:geronimo-jms_1.1_spec, Jar:geronimo-jsp_2.1_spec,
Jar:geronimo-concurrent_1.0_spec, Jar:geronimo-ws-metadata_2.0_spec,
Jar:geronimo-jaxws_2.1_spec, Jar:geronimo-activation_1.1_spec,
Jar:geronimo-saaj_1.3_spec, Jar:jstl, Jar:myfaces-api,
Jar:geronimo-jdbc, Jar:geronimo-config-groovy-transformer,
Jar:groovy-all-minimal, Jar:geronimo-transformer, Jar:sxc-jaxb,
Jar:sxc-runtime, Jar:org.apache.servicemix.bundles.jline,
Jar:org.apache.felix.configadmin, Jar:slf4j-api]
Looking in geronimo-service-builder jar I see that the core xmlbeans
files in e.g.
schemaorg_apache_xmlbeans/javaname/org/apache/xmlbeans/impl/xb/xsdschema
have been copied into our jar by the felix bundle plugin.
Is anyone else seeing this?
I'm getting fed up with the bizarre behavior of the bundle plugin and
wonder if we should try forking it and preventing our copy from
dragging in the kitchen sink from dependencies. Maybe we could make
it handle scope so the pom of bundleizing projects are usable too.
Maybe we could make it fail on split packages too.
I see what's happening, but the only current mechanism I see for getting
this correct is pretty ugly and likely error prone. At the heart of the
problem is that a bundle that uses xmlbeans needs to export all of the
packages generated under the schemaorg__apache_xmlbeans directory so
that the schema information can be located. It also needs to import
(either dynamically or explicitly) the schemaorg_apache_xmlbeans
packages of any other xmlbeans jars it depends upon, including the ones
from the xmlbeans bundle.
Currently, the export in the geronimo-service-builder is specified as
schemaorg_apache_xmlbeans*
which is picking up the generated class files for this package, but is
also pulling in all of the ones from the xmlbeans bundle as well, which
creates the split package situation. There are only a couple of types
generated, but they have very cryptic generated names. So to explicitly
specify just those types be exported, you'd need to use the following
definitions for geronimo-service-builder:
<instructions>
<!--<_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))</_versionpolicy>-->
<Import-Package>org.apache.xmlbeans.impl.schema,*</Import-Package>
<Export-Package>
org.apache.geronimo.deployment.xbeans.impl,
org.apache.geronimo.deployment.javabean.xbeans.impl,
org.apache.geronimo.deployment.xbeans*,
org.apache.geronimo.deployment.javabean.xbeans*,
schemaorg_apache_xmlbeans.javaname.org.apache.geronimo.deployment.xbeans*,
schemaorg_apache_xmlbeans.javaname.org.apache.geronimo.deployment.javabean.xbeans*,
schemaorg_apache_xmlbeans.system.sF6DA2EB01B55A149149F041F303A9AE9
schemaorg_apache_xmlbeans.element.URI_SHA_1_4EE4D506BDA8CFCEAFAFBABA17529CAACCEC8090,
schemaorg_apache_xmlbeans.namespace.URI_SHA_1_4EE4D506BDA8CFCEAFAFBABA17529CAACCEC8090,
schemaorg_apache_xmlbeans.type.URI_SHA_1_4EE4D506BDA8CFCEAFAFBABA17529CAACCEC8090,
schemaorg_apache_xmlbeans.element.URI_SHA_1_8DCD24914FA7339D843DAA772A1D3DFB2612C786,
schemaorg_apache_xmlbeans.namespace.URI_SHA_1_8DCD24914FA7339D843DAA772A1D3DFB2612C786,
schemaorg_apache_xmlbeans.type.URI_SHA_1_8DCD24914FA7339D843DAA772A1D3DFB2612C786,
org.apache.geronimo.deployment.dconfigbean,
org.apache.geronimo.deployment.service*
</Export-Package>
<DynamicImport-Package>schemaorg_apache_xmlbeans.*</DynamicImport-Package>
</instructions>
This does not look like it is something that should be done by hand. I
fixed up the service builder pom using these definitions, and the
generated bundle looks like it is correct. Other xmlbeans bundles are
even more complicated than this, so this is definitely something that
needs to be done by tooling.
I had occasion to look at the maven-bundle-plugin, and it pretty much
passes through the instructions in the configuration directly to the bnd
tools for generating the jar. Getting this correct is really just a
matter of getting instructions generated correctly, which is something
we should be able to accomplish with our own version of the plugin.
Now that we have a better understanding of what the imports/exports
should be, it should be a relatively simple matter to get a more
intelligent versions.
david jencks
