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/01/25 21:32:17 UTC
Radical structure reorg thoughts for 2.3....
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
Re: Radical structure reorg thoughts for 2.3....
Posted by Daniel Kulp <dk...@apache.org>.
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 "Richard S. Hall" <he...@ungoverned.org>.
On 1/25/10 17:38, Christian Schneider wrote:
> Hi Dan and Richard,
>
> if they can be completely separated then it is ok to give them an
> independent release number. On the other hand I don´t think it hurts a
> lot if they are built and released with the rest of cxf.
> The problem with separate releases is that you have to do the complete
> formal process like voting. I guess the additional effort could fast
> outweigh the benefits.
Yes, the voting is a PITA which is felt deeply over at the Felix
project. Part of me thinks we need to define a new process to deal with
releasing modular software because the current one sucks for that.
-> richard
>
> On the other hand it could be nice to have the build stuff that can be
> separated in a quite independent sub project. As this project would be
> quite small it could easier draw developers. The complete cxf code can
> be quite intimidating. So if you or someone else are willing to do the
> effort of separate releases I would vote for a separation.
>
> Greetings
>
> Christian
>
>
> Am 25.01.2010 22:44, schrieb Daniel Kulp:
>>
>> Yep. That's part of my point for trying to move them out to a separate
>> subproject.
>>
>> Dan
>>
>>
>
Re: Radical structure reorg thoughts for 2.3....
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Dan and Richard,
if they can be completely separated then it is ok to give them an
independent release number. On the other hand I don´t think it hurts a
lot if they are built and released with the rest of cxf.
The problem with separate releases is that you have to do the complete
formal process like voting. I guess the additional effort could fast
outweigh the benefits.
On the other hand it could be nice to have the build stuff that can be
separated in a quite independent sub project. As this project would be
quite small it could easier draw developers. The complete cxf code can
be quite intimidating. So if you or someone else are willing to do the
effort of separate releases I would vote for a separation.
Greetings
Christian
Am 25.01.2010 22:44, schrieb Daniel Kulp:
>
> Yep. That's part of my point for trying to move them out to a separate
> subproject.
>
> Dan
>
>
>
>>
--
Christian Schneider
---
http://www.liquid-reality.de
Re: Radical structure reorg thoughts for 2.3....
Posted by Daniel Kulp <dk...@apache.org>.
On Mon January 25 2010 4:32:15 pm Richard S. Hall wrote:
> On 1/25/10 16:21, Christian Schneider wrote:
> > Hi Dan,
> >
> > some comments:
> >
> > 1) If you want to give these modules owwn version I think you should
> > move them out of the main cxf tree as it would be confusing if part of
> > the tree behaves differently.
> > I would versioning like it is though. I think it does not hurt to
> > build new versions with each release. It also is easier for people
> > searching support to say "I use cxf 2.2.5" instead of "I use cxf
> > 2.2.5, xjc 2.1.1, ..."
>
> Wouldn't the CXF version imply the plugin version?
I'm talking about the xjc plugins, not the maven-codegen-plugin and other cxf
specific plugins. The xjc stuff has no dependencies on any other CXF code.
They can be used with the XJC tool that comes with Java 6 or the standalone
JAXB package. They are just plugins to XJC to enhance the way JAXB
generates code. They really aren't part of the "core functionality" of CXF.
In any case, I think 90% (or more) of the CXF users have never even used them.
:-) If you are using them, you probably know what you are doing.
> Unless they can be
> updated independently in the field after release.
They are separate jars, completely independent of everything else. Easily
upgradable. :-)
> In which case, you'd
> end up with the same situation that Linux distributions have, which
> seems to work. This is the nature of modules.
>
> From my [outsider] point of view, releasing new versions of unchanged
> modules just to keep their version numbers in sync seems to defeat some
> of the reasons of having separate modules in the first place (i.e.,
> avoiding unnecessary recompiling and repackaging).
Yep. That's part of my point for trying to move them out to a separate
subproject.
Dan
>
> -> richard
>
> > 2) same as above
> >
> > 3) I am very positive of having a cxf-core that does not need other
> > cxf modules.
> > Ideally the core should need no other dependencies at all. spring-core
> > has no dependencies and camel-core has three dependencies. Only
> > cxf-core has 23 dependencies. No one can tell me that the core of cxf
> > must be so large. I also know that it is not easy to achieve this from
> > the point where we are now.
> >
> > Apart from the effort needed to do backports for older version the
> > restructuring will probably also create incompatibilities. Still I
> > think it will be worth it.
> >
> > Greetings
> >
> > Christian
> >
> > Am 25.01.2010 21:32, schrieb Daniel Kulp:
> >> 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 "Richard S. Hall" <he...@ungoverned.org>.
On 1/25/10 16:21, Christian Schneider wrote:
> Hi Dan,
>
> some comments:
>
> 1) If you want to give these modules owwn version I think you should
> move them out of the main cxf tree as it would be confusing if part of
> the tree behaves differently.
> I would versioning like it is though. I think it does not hurt to
> build new versions with each release. It also is easier for people
> searching support to say "I use cxf 2.2.5" instead of "I use cxf
> 2.2.5, xjc 2.1.1, ..."
Wouldn't the CXF version imply the plugin version? Unless they can be
updated independently in the field after release. In which case, you'd
end up with the same situation that Linux distributions have, which
seems to work. This is the nature of modules.
From my [outsider] point of view, releasing new versions of unchanged
modules just to keep their version numbers in sync seems to defeat some
of the reasons of having separate modules in the first place (i.e.,
avoiding unnecessary recompiling and repackaging).
-> richard
> 2) same as above
>
> 3) I am very positive of having a cxf-core that does not need other
> cxf modules.
> Ideally the core should need no other dependencies at all. spring-core
> has no dependencies and camel-core has three dependencies. Only
> cxf-core has 23 dependencies. No one can tell me that the core of cxf
> must be so large. I also know that it is not easy to achieve this from
> the point where we are now.
>
> Apart from the effort needed to do backports for older version the
> restructuring will probably also create incompatibilities. Still I
> think it will be worth it.
>
> Greetings
>
> Christian
>
>
> Am 25.01.2010 21:32, schrieb Daniel Kulp:
>> 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.
>>
>
>
Re: Radical structure reorg thoughts for 2.3....
Posted by Daniel Kulp <dk...@apache.org>.
On Mon January 25 2010 4:21:47 pm Christian Schneider wrote:
> Hi Dan,
>
> some comments:
>
> 1) If you want to give these modules owwn version I think you should
> move them out of the main cxf tree as it would be confusing if part of
> the tree behaves differently.
> I would versioning like it is though. I think it does not hurt to build
> new versions with each release. It also is easier for people searching
> support to say "I use cxf 2.2.5" instead of "I use cxf 2.2.5, xjc
> 2.1.1, ..."
>
> 2) same as above
For both of these, when I said subproject, I meant a proper subproject like
the DOSGi stuff. Not in the main tree, separate "trunk" area for them.
Part of the reason is to reduce the number of modules and stuff that are
sucked into and setup in eclipse. When someone first tries to get CXF into
eclipse, it's a TON of modules. Very daunting. The xjc stuff and
buildtools is about 12 of those, yet provides very little toward actually
developing "CXF proper".
Dan
>
> 3) I am very positive of having a cxf-core that does not need other cxf
> modules.
> Ideally the core should need no other dependencies at all. spring-core
> has no dependencies and camel-core has three dependencies. Only cxf-core
> has 23 dependencies. No one can tell me that the core of cxf must be so
> large. I also know that it is not easy to achieve this from the point
> where we are now.
>
> Apart from the effort needed to do backports for older version the
> restructuring will probably also create incompatibilities. Still I think
> it will be worth it.
>
> Greetings
>
> Christian
>
> Am 25.01.2010 21:32, schrieb Daniel Kulp:
> > 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 Christian Schneider <ch...@die-schneider.net>.
Hi Dan,
some comments:
1) If you want to give these modules owwn version I think you should
move them out of the main cxf tree as it would be confusing if part of
the tree behaves differently.
I would versioning like it is though. I think it does not hurt to build
new versions with each release. It also is easier for people searching
support to say "I use cxf 2.2.5" instead of "I use cxf 2.2.5, xjc
2.1.1, ..."
2) same as above
3) I am very positive of having a cxf-core that does not need other cxf
modules.
Ideally the core should need no other dependencies at all. spring-core
has no dependencies and camel-core has three dependencies. Only cxf-core
has 23 dependencies. No one can tell me that the core of cxf must be so
large. I also know that it is not easy to achieve this from the point
where we are now.
Apart from the effort needed to do backports for older version the
restructuring will probably also create incompatibilities. Still I think
it will be worth it.
Greetings
Christian
Am 25.01.2010 21:32, schrieb Daniel Kulp:
> 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.
>
>
--
Christian Schneider
---
http://www.liquid-reality.de
Re: Radical structure reorg thoughts for 2.3....
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Dan,
how about having a real small API. Currently the cxf api consists of 41
and has a about 10k lines of code (without comments).
I don´t understand why things like transport.http or
messsage.MessageImpl and message.ExchangeImpl have to be inside API. The
same for wsdl.JAXBExtensionHelper, the whole ws.adressing and ws.policy
stuff. I would even doubt that the wsdl package is necessary. Of course
this is more something for cxf 3 ;-)
An even more radical idea would be to define an API around the core of
cxf, camel and servicemix and make this the basis of all three products.
Things like Exchange and Message would belong there. I don´t know
exactly how the scope could be set but I have the feeling that the core
ideas are more or less the same in the three products. A common API
would perhaps even make it possible to share transports, frontends and
databindings with camel and servicemix. Basically I don´t think it is
necessary to have separate http and jms transports in cxf, camel and
servicemix. In fact they do almost the same. This could allow CXF to
focus more on the ws specifications.
Greetings
Christian
Am 25.01.2010 22:53, schrieb Daniel Kulp:
> That was the original "goal" of the api module, but it hasn't worked out very
> well. Part of it is due to the "common-utilities" module which is really
> "other api's that really should have just been part of API". Another part is
> the tooling API's are completely separate as well (tools-common) so there are
> at least 3 "api" modules.
>
> The other problem we hit, (it's our own fault, only us to blame) is that we
> properly put the interfaces and such in api, but when we wrote the impls, we
> put them in the same package name, but in rt-core or the other modules. This
> REALLY prevents us from doing any real OSGi stuff other than the big bundle.
>
> The proposal wouldn't really fix that though. If api and rt/core are merged,
> SOME will be fixed, but not all of it.
>
> Another issues is that API is really "too large" now, particularly now that we
> have the JAX-RS stuff. There is a bunch of "ws specific" things in API that
> really aren't needed for JAX-RS and bring in deps that really are
> "questionable". Example, why would JAX-RS need wsdl4j? That's another
> concern we have to at least consider and see if it's something that can be
> fixed or not. (possibly not, in which case we live with it and move on)
>
>
>> I'm not very familiar with the CXF internals, so I don't know if the
>> api/rt-core separation in CXF reflects that distinction between public
>> API and internal classes, but if it does, I would suggest not to make
>> the same mistake as Axis2.
>>
> :-)
>
> Dan
>
>
>
>
>
>> Andreas
>>
>> On Mon, Jan 25, 2010 at 21:32, Daniel Kulp<dk...@apache.org> 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
>>>
>>
>
--
Christian Schneider
---
http://www.liquid-reality.de
Re: Radical structure reorg thoughts for 2.3....
Posted by Sergey Beryozkin <sb...@progress.com>.
Hi
>
> That was the original "goal" of the api module, but it hasn't worked out very
> well. Part of it is due to the "common-utilities" module which is really
> "other api's that really should have just been part of API". Another part is
> the tooling API's are completely separate as well (tools-common) so there are
> at least 3 "api" modules.
>
> The other problem we hit, (it's our own fault, only us to blame) is that we
> properly put the interfaces and such in api, but when we wrote the impls, we
> put them in the same package name, but in rt-core or the other modules. This
> REALLY prevents us from doing any real OSGi stuff other than the big bundle.
>
> The proposal wouldn't really fix that though. If api and rt/core are merged,
> SOME will be fixed, but not all of it.
>
> Another issues is that API is really "too large" now, particularly now that we
> have the JAX-RS stuff. There is a bunch of "ws specific" things in API that
> really aren't needed for JAX-RS and bring in deps that really are
> "questionable". Example, why would JAX-RS need wsdl4j? That's another
> concern we have to at least consider and see if it's something that can be
> fixed or not. (possibly not, in which case we live with it and move on)
>
If CXF has WSDL2 implementing at some time in the future then CXF JAXRS might let users see WSDL2 views of the JAXRS services which
can be of special interest to users doing both soap and rest given that they will have an option of using a single document
describing both soap and rest endpoints. But I don't know at the moment if/when it will happen...Perhaps the most immediate fix for
this issue (JAXRS services requiring a wsdl4j dependency) is to ensure a WSDLManager is not loaded for JAXRS-only, I believe it is
still the case for 2.3 (I will create a test project).
The other thing to consider is that after 2.3 gets released, the security support may become one of the major themes for CXF JAXRS.
Not sure at this moment how much will be done for 3.0/(2.4 ?) but I reckon there's plenty of code in the ws modules which can be
reused by the JAXRS code (ex, to do with the message-level security). Thus I'd be looking into creating a common security api as
well.
JAXRS services depend internally on the generated EndpointReferenceType. It's a WSA specific artifact/'term' but it's a generated
class which can help JAXRS services just fine.
I guess, strategically, there're two approaches toward defining the 'relationship' between the whole of CXF and its JAXRS module.
One is to continue viewing CXF JAXRS as one of the CXF frontends. Another, as suggested earlier on, is to move it into a separate
subproject. The former approach puts some pressure on the cxf-api, there're few bits there which are not needed by cxf jaxrs. The
latter would keep a clear separation between CXF the SOAP and CXF JAXRS but would still keep the pressure on the cxf-api. I'm in
favor of the 1st approach. IMHO the1st approach has many advantages, one of them is that is that it is not SOAP vs REST after all,
the other to do with the speed of development, etc...
Sergey
Re: Radical structure reorg thoughts for 2.3....
Posted by Daniel Kulp <dk...@apache.org>.
On Mon January 25 2010 4:22:45 pm Andreas Veithen wrote:
> Daniel,
>
> "cxf-kernel" sounds very Axis2-ish ;-)
OK. cxf-core it is. :-)
> More seriously, one of the big design issues in Axis2 is that there is
> no separation between API and core/kernel. We just have that
> axis2-kernel module containing a huge amount of classes of different
> kinds (real APIs/SPIs, internal implementation classes and utility
> classes). That makes it very hard to distinguish the public API (which
> should be as stable as possible) from those classes that may change
> more frequently. If there is ever an Axis3 (or Axis 3.0 ;-), I would
> suggest to do that split.
That was the original "goal" of the api module, but it hasn't worked out very
well. Part of it is due to the "common-utilities" module which is really
"other api's that really should have just been part of API". Another part is
the tooling API's are completely separate as well (tools-common) so there are
at least 3 "api" modules.
The other problem we hit, (it's our own fault, only us to blame) is that we
properly put the interfaces and such in api, but when we wrote the impls, we
put them in the same package name, but in rt-core or the other modules. This
REALLY prevents us from doing any real OSGi stuff other than the big bundle.
The proposal wouldn't really fix that though. If api and rt/core are merged,
SOME will be fixed, but not all of it.
Another issues is that API is really "too large" now, particularly now that we
have the JAX-RS stuff. There is a bunch of "ws specific" things in API that
really aren't needed for JAX-RS and bring in deps that really are
"questionable". Example, why would JAX-RS need wsdl4j? That's another
concern we have to at least consider and see if it's something that can be
fixed or not. (possibly not, in which case we live with it and move on)
> I'm not very familiar with the CXF internals, so I don't know if the
> api/rt-core separation in CXF reflects that distinction between public
> API and internal classes, but if it does, I would suggest not to make
> the same mistake as Axis2.
:-)
Dan
>
> Andreas
>
> On Mon, Jan 25, 2010 at 21:32, Daniel Kulp <dk...@apache.org> 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
>
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Radical structure reorg thoughts for 2.3....
Posted by Andreas Veithen <an...@gmail.com>.
Daniel,
"cxf-kernel" sounds very Axis2-ish ;-)
More seriously, one of the big design issues in Axis2 is that there is
no separation between API and core/kernel. We just have that
axis2-kernel module containing a huge amount of classes of different
kinds (real APIs/SPIs, internal implementation classes and utility
classes). That makes it very hard to distinguish the public API (which
should be as stable as possible) from those classes that may change
more frequently. If there is ever an Axis3 (or Axis 3.0 ;-), I would
suggest to do that split.
I'm not very familiar with the CXF internals, so I don't know if the
api/rt-core separation in CXF reflects that distinction between public
API and internal classes, but if it does, I would suggest not to make
the same mistake as Axis2.
Andreas
On Mon, Jan 25, 2010 at 21:32, Daniel Kulp <dk...@apache.org> 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
>