cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Systests build problem
Date Fri, 14 Sep 2007 21:02:34 GMT


James,

Due to a bug in maven, the FIRST time a plugin is encountered, the 
classloader for that plugin is setup based on the dependencies at that 
time.   It's not done for each invoke of the plugin.   When run from 
root, the first time is in testutils (I think, maybe sooner) and thus 
doesn't get the soap dependency.   When it gets to systest, the soap is 
not there.   If you run from systest, that is the first invokation and 
thus it gets added to the plugins classloader.   (FYI: this is supposed 
to be fixed in Maven 2.1, but not the 2.0.x series as it would break too 
many builds that rely on the broken behavior)

The issue is that when the bus is created inside the tools, it uses the 
current context classloader, NOT the system.classpath system property.  
You can set that property all you want and it won't do any good.    What 
my suggestion was to use the artifacts to build up a classpath and fork 
java to run the tools in a separate JVM.   Thus, the current classloader 
would be irrelevant.    It would be a -classpath param to java, not to 
the wsdl2java tool.   


Dan




On Monday 10 September 2007, James Mao wrote:
> Hi Dan,
>
> >> Interesting, do you mean add another argument 'classpath' into the
> >> wsdl2java mojo?
> >> Is it easy to parse the dependencies to the 'classpath' ?
> >
> > No, I mean adding:
> >  * @requiresDependencyResolution runtime
> > (maybe test, not sure, probably test)
> > to the classlevel javadoc and then calling
>
> I tried, but not working, actually before adding the
> @requiresDependencyResolution, I can see the soap is in the classpath,
>
> > for ( Iterator it = project.getArtifacts().iterator() ; it.hasNext()
> > ;){ Artifact artifact = (Artifact) it.next();
> > ...
> > }
>
> Also tried this, add all the jar into the classpath, and from the
> classpath, I can confirm that it's added into the classpath, but still
> not working.
>
> Is it a bug of Maven? Why it works in the systests module, but failed
> in the top level,  I can tell from the output of classpath, they are
> same.
>
> Thanks,
> James
>
> > to get the jars that/artifacts that the project depends on. 
> > Basically, the pom has a list of dependencies for that project,
> > let's use them.
> >
> > Dan
> >
> >> Thanks,
> >> James
> >>
> >>> I think the proper fix would be to update the wsdl2java (and
> >>> java2wsdl) maven plugin to use the project dependencies itself in
> >>> addition to it's own plugin dependencies.   We already buildup a
> >>> "classpath" in the tools for the tool to look up the java classes
> >>> for java2wsdl.   We should just go ahead and use it for everything
> >>> including the "plugins".
> >>>
> >>> Probably the best option would be to change the plugin to create a
> >>> full classpath (project + plugin jars/deps) and fork the code
> >>> gen/wsdl gen. That would avoid some memory issues in Maven as
> >>> well.
> >>>
> >>> Dan
> >>>
> >>> On Thursday 06 September 2007, James Mao wrote:
> >>>> Hi Sergey,
> >>>>
> >>>> I struggled a day, and still can not figure out how to solve it,
> >>>> I've upgraded to mvn 2.0.7, but still can not solve the problem.
> >>>>
> >>>> In systests, if you print the classpath, you will find the jar
> >>>> cxf-rt-bindings-soap-2.1-incubator-SNAPSHOT.jar  is in your
> >>>> classpath,
> >>>>
> >>>> However, if you build from the top level, in the classpath it
> >>>> include the
> >>>> C:\src\java\apache\cxf\rt\bindings\soap\target\classes
> >>>>
> >>>> And for some unknown reason, the code-gen plugin just can not
> >>>> load the soap binding even though you defined the soap in the
> >>>> dependencies, very strange.
> >>>>
> >>>> I felt that this's a bug in maven.
> >>>>
> >>>> There's one solution to solve this problem, that's define the
> >>>> soap binding in the code-gen plugin,
> >>>> but then we'll have the cyclic dependencies:
> >>>> soap->jaxb->testutil->codegen->soap
> >>>> To solve the cyclic dependency, we have to move the tests to
> >>>> systests module, or create a new test module...
> >>>>
> >>>> Any good suggestions?
> >>>>
> >>>> James
> >>>>
> >>>>> If you build from top level, you'll not have the problem,  the
> >>>>> maven code-gen plugin , just can not load the soap module,
> >>>>> I'll take look at it tomorrow, maybe disable the test, and will
> >>>>> re-enable it later, if we resolve the dependencies.
> >>>>>
> >>>>> Cheers,
> >>>>> James
> >>>>>
> >>>>>> Hi
> >>>>>>
> >>>>>> I can not build CXF on Windows. The failure occurs in the
> >>>>>> systests module :
> >>>>>>
> >>>>>> HeaderClientServerTest.java:[62,41]
> >>>>>> orderPizza(org.apache.cxf.pizza.types.
> >>>>>> OrderPizzaType,org.apache.cxf.pizza.types.CallerIDHeaderType)
> >>>>>> in org.apache.cxf.
> >>>>>> pizza.Pizza cannot be applied to
> >>>>>> (org.apache.cxf.pizza.types.OrderPizzaType)
> >>>>>>
> >>>>>> trunk/systests have a generated folder where
> >>>>>> org.apache.cxf.pizza.Pizza is located, it has a method :
> >>>>>>
> >>>>>> orderPizza(org.apache.cxf.pizza.types.OrderPizzaType,org.apache
> >>>>>>.c xf .pizza.types.CallerIDHeaderType)
> >>>>>>
> >>>>>>
> >>>>>> here's code in the HeaderClientServerTest.java :
> >>>>>>
> >>>>>> OrderPizzaResponseType res = port.orderPizza(req);
> >>>>>> System.out.println(res);
> >>>>>>
> >>>>>> //OrderPizzaResponseType res =  port.orderPizza(req, header);
> >>>>>> //assertEquals(208, res.getMinutesUntilReady());
> >>>>>>
> >>>>>> The test is basically disabled and it also doesn't compile.
> >>>>>> Uncommenting the above two lines makes the test compile and
> >>>>>> pass. Not sure what the story with test is, but as far as the
> >>>>>> compliation is concerned I reckon I'm picking up some stale
> >>>>>> module which affects the wsdl generation ?
> >>>>>>
> >>>>>> can someone please advise on how to deal with issues like this
> >>>>>> one ? I've removed a cxf directory in the local repo, created
a
> >>>>>> new snapshot, no luck....
> >>>>>>
> >>>>>> Thanks, Sergey
> >>>>>>
> >>>>>> ----------------------------
> >>>>>> IONA Technologies PLC (registered in Ireland)
> >>>>>> Registered Number: 171387
> >>>>>> Registered Address: The IONA Building, Shelbourne Road, Dublin
> >>>>>> 4, Ireland



-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog

Mime
View raw message