Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of james.mao@iona.com designates
 12.170.54.180 as permitted sender)
Message-ID: <46E4F3C0.3070607@iona.com>
Date: Mon, 10 Sep 2007 15:35:28 +0800
From: James Mao <james.mao@iona.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Daniel Kulp <dkulp@apache.org>
CC: cxf-dev@incubator.apache.org
Subject: Re: Systests build problem
References: <008b01c7eef2$bd284de0$e002050a@pcgroupiona.com>
 <200709061226.00709.dkulp@apache.org> <46E0FDB0.6040904@iona.com>
 <200709070908.17186.dkulp@apache.org>
In-Reply-To: <200709070908.17186.dkulp@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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