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.
