cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Mao <>
Subject Re: svn commit: r527347 - in /incubator/cxf/trunk: rt/bindings/object/ rt/bindings/object/src/main/java/org/apache/cxf/binding/object/ rt/bindings/object/src/main/resources/META-INF/cxf/ rt/bindings/object/src/test/java/org/apache/cxf/binding/object/
Date Thu, 12 Apr 2007 03:54:10 GMT
Hi Dan,

Make sure my point is clear

I'm OK to bundle the jaxws/jaxb as a default tool plugin into the single 
Previous plugin description already works in this way.
What i think is <plugins> is a redundant. i think we can safely revert 
to previous implementation.

just put one tools-plugin.xml into META-INF dir and include jaxws 
frontend and jaxb databinding inside the <plugin> should fit the 


> Hi Dan,
>> Hi James,
>> Two quick things before I revert:
>> 1. How would I merge the various <plugin> attributes from the 
>> different xml
>> files? i.e. they both have different name attributes. What should I 
>> do when
>> combining the different tools.xml into 1 xml file? Or is that 
>> attribute not
>> even really used?
> To combine is not a good idea, databinding and fronetend they are 
> different things, if you take a look at the svn log, i did it before, 
> it's looks like this:
> <plugin name="cxf.default" provider="">
>   <frontend name="jaxws">
>    ...
>  </frontend>
>  <databinding name="jaxb">
>  ...
>  </databinding>
> </plugin>
> it works, but i think it's not good, so i separated, and keep every 
> part independent with each other. and also move the plugin description 
> into META-INF dir.
> The plugin node actually just a wrap element, what really we care is 
> the frontend  and databinding inside the element.
>> 2. You'll still be able to use the tools separated, but as we agreed 
>> on the
>> mailing list, it'd be great if we could produce a cxf.jar with 
>> everything,
>> including the tools modules so users only need to manage one jar.
> It's ok to have a single jar, but i don't think we need put the 
> plugins inside the jar, that does not make much sense to me.
> Take eclipse as an example, you can have a core eclipse, but other 
> extensions are independent jars, you can download from eclipse/plugins
> I would suggest that we pack Common/Api/Rt/ToolCore    and keep the 
> plugins out side of the single jar, just like you are not going to put 
> the codegen plugins/ eclipse plugins/ jdee plugins inside the single 
> jar, right?
> For your reference
> Cheers,
> James.

View raw message