geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <rick...@gmail.com>
Subject Re: More build problems in trunk
Date Tue, 10 Nov 2009 12:01:01 GMT
Rick McGuire wrote:
> 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.
ok, while starting to look at what it might take to implement something 
here, I discovered the plugin already has an option that will prevent 
the extra packages from getting inlined in the bundle.  If the export of 
the schemaorg_apache_xmlbeans* package is done using <_exportcontents> 
rather than <Export-Package>, then the inlining of the xmlbeans base 
files does not occur.

Rick
>>
>> david jencks
>>
>>
>
>


Mime
View raw message