Gary, I've definitely thought about that. The issue now is compatibility. If people are subclassing org.apache.cxf.interceptor.BareInInterceptor, and we move it, they have to update code. I have no problem with that, we just need to start a section on the wiki for "2.1 migration guide" information so we make sure it's all tracked.
First step is probably finding the packages that would be affected so we can examine them. The other issue that keeps popping up is whether cxf-common-utilities, cxf-api, and cxf-rt-core SHOULD be merged into one. IMO, common-utilities and cxf-api really should be merged together as they both really are the API's. I could also see much of core since a LOT of the rest of the stuff depends on stuff there. Thus, should they be "api" and not "impl" things? It's an interesting discussion. Dan On Thursday 20 September 2007, Tully, Gary wrote: > Hi Dan, > When looking at CXF from an OSGi bundle perspective the duplication of > packages between api and implementation limits the modularity. Both > interface and implementation are available to dependants by default. > > Would we consider adding an .impl to the implementation package names > in CXF. > > org.apache.cxf.interceptor.Inerceptor > org.apache.cxf.interceptor.impl.BareInInterceptor > > This would help Message.properties also. > > Best Regards, > Gary. > > > -----Original Message----- > > From: Daniel Kulp [mailto:[EMAIL PROTECTED] > > Sent: 20 September 2007 01:48 > > To: [email protected] > > Cc: Christian Schneider > > Subject: Re: Architecture of cxf > > > > > > We have a few places where package names exist in both the API jar > > as well as in the rt-* jars. This may be causing some issues with > > the analysis. They CERTAINLY have caused issues with the i18n > > stuff as grabbing the Message.properties seems to grab > > whichever is in the > > classpath first. Definitely something I'd like to see cleaned up. > > > > Dan > > > > On Wednesday 19 September 2007, Christian Schneider wrote: > > > I have done a second try at displaying the architecture. > > > > This time I > > > > > only included the cxf-rt* jars in the model. > > > This looks much better already ;-) Any idea why inlcuding the > > > other jars especially the api jar gave me so many cycles? > > > > > > This architecture view below shows only some cycles. > > > > > > Best regards > > > > > > Christian Schneider > > > > -- > > J. Daniel Kulp > > Principal Engineer > > IONA > > P: 781-902-8727 C: 508-380-7194 > > [EMAIL PROTECTED] > > http://www.dankulp.com/blog > > ---------------------------- > IONA Technologies PLC (registered in Ireland) > Registered Number: 171387 > Registered Address: The IONA Building, Shelbourne Road, Dublin 4, > Ireland -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
