You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Daniel Kulp <dk...@apache.org> on 2010/02/01 21:41:53 UTC

Re: Radical structure reorg thoughts for 2.3....

 

It looks like we have a semi-concensus at least for the first two parts.   
Basically, create a subproject for the xjc related stuff to kind of be a more 
"open" jaxb-commons type thing.   (and the build-utils subproject to support 
both this and the normal cxf stuff and potentially dosgi as well).

If there are no objections, I'll start working on that on Wednesday.  Thus, 
speak up if you object.   (or, speak up if you think we need a formal vote on 
this.   I'm happy with lazy concensus, but if someone wants a formal vote, I'd 
be happy to do that as well).

We can tackle #3 separately.   

Dan



On Mon January 25 2010 3:32:17 pm Daniel Kulp wrote:
> I'd like everyone's thoughts on some ideas I have to do some minor
> restructuring for 2.3.  I'm just throwing this out there as some ideas.  
>  We don't need to do any of this if people disagree or would find it
>  annoying or similar.   I just want peoples thoughts....
> 
> 1) We have a bunch of xjc plugins in common/xjc that really never change.
> There really isn't a reason to have a 2.3 version and a 2.2.6 version and
> such.   They are pretty much completely shareable.    Thus, I'm thinking of
> creating an "xjc-plugins" sub-project to house these.  We could just
>  release them once and re-use them until new plugins are needed/created.  
>  common/xsd (our xjc wrapper maven plugin) would probably go there as well.
> 
> 2) Likewise, buildtools and maven-plugins/xml2fastinfoset-*  are really
>  RARELY changed.   I'd like to have a "build-tools" subproject for these
>  type things. This is partially to support (1) above so the checkstyle
>  rules and such are more shareable, but it also would remove a few modules
>  from the build.
> 
> 3) Most radical idea:   I'd like to merge what's left in common/*  after
>  (1) into api.   Possibly also merge parts or all of rt/core into API.   If
>  we do that, possibly just rename api to "cxf-kernel" or make it cxf-core
>  or similar. common-utilities, api, and core are really not useable without
>  each other at all.   You cannot do much without all three so merging them
>  together seems to make some sense.    POSSIBLY tools-common as well.   I 
>  need to look into that one a bit more.    We COULD potentially move some
>  stuff OUT of api/rt-core that is more ws specific (like the wsdl manager
>  stuff) and into a ws-core or something that wouldn't be needed for JAX-RS.
>    Not sure how much of an impact that would have.
> 
> Doing 3 MAY allow better OSGi support as we really would have a "kernel"
>  with pretty much EVERYTHING else being plugins into our kernel.
> 
> There will be a slight build speedup as less modules are built and less
>  calls to checkstyle and such, but nothing major as a majority is in the
>  systests. Now that we've gone with Surefire 2.5, I MAY experiment with the
>  parallel setting on a couple of the module, probably cannot on the
>  systests though.
> 
> Now, the MAIN drawback from all this would be merging fixes to 2.2.x is
>  going to be much harder in those modules.   I think that would mostly
>  affect me though.
> 
> Anyway, I'd like to know what people think about all this.
> 

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

Re: Radical structure reorg thoughts for 2.3....

Posted by Daniel Kulp <dk...@apache.org>.
Since there were not any objections or anything, I'll go ahead and start 
working on some of this.   

Thanks!

Dan


On Mon February 1 2010 3:41:53 pm Daniel Kulp wrote:
> It looks like we have a semi-concensus at least for the first two parts.
> Basically, create a subproject for the xjc related stuff to kind of be a
>  more "open" jaxb-commons type thing.   (and the build-utils subproject to
>  support both this and the normal cxf stuff and potentially dosgi as well).
> 
> If there are no objections, I'll start working on that on Wednesday.  Thus,
> speak up if you object.   (or, speak up if you think we need a formal vote
>  on this.   I'm happy with lazy concensus, but if someone wants a formal
>  vote, I'd be happy to do that as well).
> 
> We can tackle #3 separately.
> 
> Dan
> 
> On Mon January 25 2010 3:32:17 pm Daniel Kulp wrote:
> > I'd like everyone's thoughts on some ideas I have to do some minor
> > restructuring for 2.3.  I'm just throwing this out there as some ideas.
> >  We don't need to do any of this if people disagree or would find it
> >  annoying or similar.   I just want peoples thoughts....
> >
> > 1) We have a bunch of xjc plugins in common/xjc that really never change.
> > There really isn't a reason to have a 2.3 version and a 2.2.6 version and
> > such.   They are pretty much completely shareable.    Thus, I'm thinking
> > of creating an "xjc-plugins" sub-project to house these.  We could just
> > release them once and re-use them until new plugins are needed/created.
> > common/xsd (our xjc wrapper maven plugin) would probably go there as
> > well.
> >
> > 2) Likewise, buildtools and maven-plugins/xml2fastinfoset-*  are really
> >  RARELY changed.   I'd like to have a "build-tools" subproject for these
> >  type things. This is partially to support (1) above so the checkstyle
> >  rules and such are more shareable, but it also would remove a few
> > modules from the build.
> >
> > 3) Most radical idea:   I'd like to merge what's left in common/*  after
> >  (1) into api.   Possibly also merge parts or all of rt/core into API.  
> > If we do that, possibly just rename api to "cxf-kernel" or make it
> > cxf-core or similar. common-utilities, api, and core are really not
> > useable without each other at all.   You cannot do much without all three
> > so merging them together seems to make some sense.    POSSIBLY
> > tools-common as well.   I need to look into that one a bit more.    We
> > COULD potentially move some stuff OUT of api/rt-core that is more ws
> > specific (like the wsdl manager stuff) and into a ws-core or something
> > that wouldn't be needed for JAX-RS. Not sure how much of an impact that
> > would have.
> >
> > Doing 3 MAY allow better OSGi support as we really would have a "kernel"
> >  with pretty much EVERYTHING else being plugins into our kernel.
> >
> > There will be a slight build speedup as less modules are built and less
> >  calls to checkstyle and such, but nothing major as a majority is in the
> >  systests. Now that we've gone with Surefire 2.5, I MAY experiment with
> > the parallel setting on a couple of the module, probably cannot on the
> > systests though.
> >
> > Now, the MAIN drawback from all this would be merging fixes to 2.2.x is
> >  going to be much harder in those modules.   I think that would mostly
> >  affect me though.
> >
> > Anyway, I'd like to know what people think about all this.
> 

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog