Hi Dan, I was not really happy with the problem described by Mandy: to have some API classes available for more than one application (Destination, Conduit and AbstractTransportFactory in that case) we need to share whole Spring dependencies as well.
Therefore I find the idea to separate spring and blueprint dependent classes great and very useful. @Sergey: I think the most important is to extract bus.spring.* and configuration.spring.* classes, often used to instantiate bus, servers and proxies from spring configuration. Spring AOP + Class scanner are not so critical from my perspective. Regarding the release: of course, would be nice to have this in 3.0.0, but agree with Sergei that it is a big change requiring additional tests (especially for OSGi), documentation updates, migration guides. My +1 for pursue it in 3.1.0. Regards, Andrei. > -----Original Message----- > From: Daniel Kulp [mailto:[email protected]] > Sent: Donnerstag, 1. Mai 2014 18:03 > To: [email protected] > Subject: Re: Repackaging of cxf-api to remove Spring dependencies > > > I decided to try and experiment a bit with this idea. Just pushed a > "split-spring" > branch for folks to look at. > > Basically, I did a few things: > > 1) Pulled bus/spring and configuration/spring into a new rt/spring bundle > 2) Pulled bus/blueprint and configuration/blueprint (and related blueprint > only > schemas) into a new rt/aries-blueprint bundle > 3) updated all the poms/features.xml to pull them (optional for cxf-spring and > provided+optional for cxf-aries-blueprint) > > Cuts the core jar by about 105K. > > This does result in cxf-core not having any blueprint/aries deps at all. The > other bundles do, but core doesn't. Core still has a couple of spring deps > though. There is the SpringBeanFactory invoker thing, the helper for dealing > with AOP classes, and the new classpath scanning stuff. The > SpringBeanFactory could be moved to cxf-spring if we change the > @FactoryType annotation a bit so "Spring" is not one of the core types. Not a > big deal. The AOP handling and classpath scanning stuff would be a bigger > issue though. > > > So, the question is, do we want to pursue this further for 3.0 or not? For > spring users, they would need to add cxf-spring to the deps (minor) update and > they would save about 40K due to lack of the aries stuff. For non-spring > users, > they could save 105K in space. We'd certainly need to go back and retest > the > samples and OSGi stuff which could be a big undertaking. > > > Thoughts? > > Dan > > > > > On Apr 30, 2014, at 7:12 PM, Daniel Kulp <[email protected]> wrote: > > > > > Just about every jar that has any level of significantly configurable > functionality in CXF has some classes in it that depend on spring. jaxws, > jaxrs, > http, ws-security, ws-policy, etc.... I certainly would NOT want to just > about > double the number of jars/modules we have to deal with to pull spring out of > everything and into separate jars. > > > > That said, spring should be completely optional. If the spring jars are not > there, CXF should be able to detect that and work fine without it (minus all > the > xml configuration and the JMS transport). > > > > With 3.0, it's even a bit more complicated as API is gone and merged with > cxf-rt-core into just cxf-core. Would definitely need to play more to > figure out > what spring stuff could even be pulled out there successfully. > > > > Dan > > > > > > > > > > On Apr 30, 2014, at 3:57 PM, Mandy Warren <[email protected]> > wrote: > > > >> Hi, > >> > >> I am working on a new transport which will look very much like > >> LocalTransport but use JNDI to register the destinations. The idea is > >> that this will allow for war-war comms on a single thread with only a > >> very minimal set of jars on the system classpath. > >> > >> I've successfully prototyped this and run the initial code past > >> Andrei, I am now trying to productionise it so I can get this groups > >> feedback as to whether it could be a useful addition to CXF. > >> > >> One thing which my solution requires is for the Spring dependencies > >> in cxf-api to be moved into their own jar. This way, all I require on > >> the shared classpath is the cut down cxf-api and not all the Spring > >> libraries. > >> > >> I was wondering whether you would consider this repackaging as an > >> option for a future release? There are only a very small amount of > >> classes which would need to be moved, namely those in > >> cxf/api/src/main/java/org/apache/cxf/configuration/spring > >> > >> Many thanks > >> > >> Mandy > >> <https://fisheye6.atlassian.com/browse/cxf> > > > > -- > > Daniel Kulp > > [email protected] - http://dankulp.com/blog Talend Community Coder - > > http://coders.talend.com > > > > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog Talend Community Coder - > http://coders.talend.com
