+1 for removing the big bundles.
Christian
Am 03.09.2013 19:09, schrieb Daniel Kulp:
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?
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
