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 [email protected] http://www.dankulp.com/blog
