cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Freeman Fang <>
Subject Re: [DISCUSS] Big bundles for 3.0....
Date Tue, 03 Sep 2013 23:51:31 GMT
+1 for doing it in 3.0
Freeman(Yue) Fang

Red Hat, Inc. 
FuseSource is now part of Red Hat
Web: |
Twitter: freemanfang
weibo: @Freeman小屋

On 2013-9-4, at 上午1:09, Daniel Kulp wrote:

> 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
> -
> Talend Community Coder -

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message