geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <>
Subject Re: Strange dependency problem building jaxws
Date Wed, 11 Nov 2009 10:29:36 GMT
David Jencks wrote:
> On Nov 10, 2009, at 9:57 AM, Rick McGuire wrote:
>> David Jencks wrote:
>>> On Nov 10, 2009, at 7:59 AM, Rick McGuire wrote:
>>>> There are two subprojects in the jaxws plugin that I'm having 
>>>> trouble building, and I can't figure out why.  The cause of the 
>>>> failure is a resolution failure trying to resolve the javax.jws 
>>>> package, version 2.0.  These classes are contained in the 
>>>> geronimo-ws-metadata specs bundle, and should be there.  Running 
>>>> the build with the -X option does not show any sign that this 
>>>> bundle is getting installed and started before the error.  I've 
>>>> tried adding this as dependency in every pom I could think of to 
>>>> force this to be loaded first and nothing appears to have made a 
>>>> difference.  That bundle just doesn't seem to get loaded.  The 
>>>> manifests look good in all cases, but it just doesn't appear to load.
>>>> I also tried specifying a version in the karaf on 
>>>> the javax.jws packages, but that didn't make any difference 
>>>> either.  There's obviously something going wrong with how the 
>>>> dependencies are processed here, but I can't seem to spot what's 
>>>> messing up.  Everything looks like what I'd expect to see when I 
>>>> use dependency:tree.
>>>> For now, I've just commented these two items out so they won't 
>>>> build, but this is going to need to be solved eventually.
>>> I suspect these classes are also in the jvm.  Maybe the situation is 
>>> similar to the one for javax.transaction where some classes come 
>>> from the jvm and some from the spec jar?  The mysterious fix for 
>>> that seems to be, in etc/ from 
>>> framework/config/karaf-framework/src/main/resources/filtered-resources/etc/

>>> org.osgi.framework.bootdelegation=sun.*,com.sun.*,javax.transaction,javax.transaction.*

>>> and
>>> javax.transaction; javax.transaction.xa; partial=true; 
>>> mandatory:=partial, \
>> I did that experiment already, and that didn't work either.  The root 
>> of the problem appears to be the explicit request for the 2.0 
>> version.  That is available in the geronimo-ws-metadata bundle, but 
>> there's no sign in any of the Felix debug output to indicate that 
>> this is getting loaded.
>> I'm now stuck on a similar situation with geronimo-service-builder.  
>> I'm getting a constraint loading error on geronimo-service-builder 
>> because it can't find the org.apache.geronimo.xbeans.j2ee package.  
>> That's in the geronimo-schema-jee_5.1.2 bundle, but again, I'm not 
>> seeing that bundle loaded before the geronimo-service-builder bundle, 
>> so the geronimo-service-builder can't be resolved.  It's really 
>> looking like there's an ordering problem in the dependency manager 
>> that's resulting in bundles not getting installed before the bundles 
>> that depend on them.
> I don't have time to look into it right now.... I thought I made the 
> dep-manager install all the bundles then run through and try to  start 
> them to avoid this problem.  I expected that if we got a jar into the 
> dependencies list it would then be installed and known to felix before 
> we actually needed any of its classes.  Not sure if this makes sense 
> or if I got the code in to actually do this...
I think I figured out the root cause of this.  A lot of poms had a 
dependency for geronimo-gbean-deployer with a scope of provided


This resulted in all of the dependencies of geronimo-gbean-deployer 
getting marked as provided also.  As a result, even if you explicitly 
added one of these dependencies to a plugin that had a dependency on 
geronimo-gbean-deployer, it was not getting installed because that 
dependency was already marked as "provided".  It appears that the 
reasons for geronimo-gbean-deployer being marked as provided must be 
obsolete or else this somehow needs to be forced to load somewhere in 
the dependency manager.

> david jencks
>> Rick
>>> Might be worth experimenting with anyway.
>>> david jencks
>>>> Rick

View raw message