Honestly, one of the things I keep thinking about for 3.0 is combining common-utilities, api, and rt/core into a single "cxf-kernel" or something. common-utilities and api seperation is pretty much useless. The utilities are as much a part of the api as the stuff in the api module is. The reason they were separated goes WAY WAY back to M1 days when the tools didn't depend on core. That reason is now long gone and having them separate is almost pointless.
But to this discussion, making the API module depend on less things really won't solve the problem at all. You cannot really do anything without depending on cxf-rt-core. Thus, if you move a dependency from API to core, it doesn't change the fact that it would get pulled in for any cxf application. Dan On Tuesday 02 December 2008 2:50:14 am Christian Schneider wrote: > Hi Dan, > > I can imagine that every single jar is needed right now but I think the > dependencies show that there are things in the api that do not belong > there. > > For example I tried to find out why cxf-common-utilities is needed. It > seems it is only used in one class: TransportURIResolver. > This class is an implementation class and also seems not to be > referenced from the rest of the API module. So I guess it should be > moved to cxf-common-utils or cxf-rt-core. > > I think the neethi package is really not that critical. > > Greetings > > Christian > > > Honesly, I'm not sure if anything there is actually removable. MAYBE > > mark Neethi as provided, but it would still be pulled in later. > > xml-resolve could potentially be pulled if we add code to detect it's not > > there and then not support catalogs in that case. -- Daniel Kulp [EMAIL PROTECTED] http://dankulp.com/blog
