+1 from me, it is a bit confusing at the moment. Regards, Andrei.
> -----Original Message----- > From: Daniel Kulp [mailto:[email protected]] > Sent: Dienstag, 3. September 2013 19:10 > To: [email protected] > Subject: [DISCUSS] Big bundles for 3.0.... > > > I'd like to get rid of the 3 big bundles for 3.0 and want to get other's > thoughts.... > > Basically, I little history behind them..... > > A long long time ago, we decided to use shade to create a single big jar that > can stick in the "lib" directory of the distribution to reduce the number of > jars > in the lib dir and on the classpath. Personally, I really don't care about > the > number of jars, (especially considering the number of 3rd party jars we have > in there already) but some people did so the bundle was created. The > individual modules are still part of the distro in the modules dir, so much of > the functionality is in the distro twice. We already have the "cxf- > manifest.jar" jar which pulls in all the individual jars for javac and > runtime so > all the little jars are not required on the classpath to avoid the classpath > length limits. > > Anyway, when we started looking at OSGi, due to all the split-package issues, > we decided the easiest way to support CXF in OSGi was to add the OSGi > metadata to the big jar. Thus, it became an OSGi bundle. > > When DOSGi came along, we decided the bundle was too big and created > the "minimal" bundle. > > Likewise, JAX-RS folks wanted a JAX-RS only bundle. > > Thus, we ended up with 3 big bundles. > > > HOWEVER, a lot has changed since then: > > 1) For starters, all the split-package things are resolved and each jar is > it's > own OSGi bundle. Additionally, many of the bundle have their own > activators and such that do NOT work with the big bundle. The features.xml > and such were all updated to use the little jars. If using 2.6.x or newer > in > OSGi, it's strongly recommended to use the individual bundles as that's all > that is tested. > > 2) DOSGi has "grown" and thus the minimal bundle has grown to include > most of the stuff in the "all" bundle. It's really not minimal at all > anymore. If > you DO need a minimal CXF environment, you are WAY WAY better off > grabbing the individual jars/bundles you need. You can create a much > smaller set than even the minimal bundle provided. DOSGi has also changed > to using the individual bundles instead of the big bundle anyway. > > 3) Likewise with JAX-RS. With the individual jars, you can create a much more > tailored and smaller runtime (especially on 3.0/trunk due to the dependency > cleanups) > > 4) Services - none of the services (STS, WSN, WS-Discovery, etc...) are in the > big bundles anyway and thus are stuck as jars in the lib dir. The XJC > runtime > and plugins are pulled out as well. > > 5) More people using Maven - with a majority of CXF users likely using > Maven instead of Ant or other tools and Maven handling all the little jars > fairly well, I believe very few people use the big bundles. > > > Anyway, I'd like to go ahead and remove all three of them for 3.0. It > would > result in a smaller distribution, the OSGi story is clearer, it simplifies > (and > speeds up) the build a little bit, etc... > > The downside being a lot of cxf-*.jar's in the distribution's lib directory. > If > this is too much of a downside, we could keep the "all" bundle, but I'd > recommend removing all the OSGi stuff from it so there is no confusion that > this is not for OSGi. That said, I just don't think we need it at all. > > Thoughts? > > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog Talend Community Coder - > http://coders.talend.com
