cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject [DISCUSS] Big bundles for 3.0....
Date Tue, 03 Sep 2013 17:09:48 GMT

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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


Mime
View raw message