Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: error (athena.apache.org: local policy)
From: Daniel Kulp <dkulp@apache.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: [DISCUSS] Big bundles for 3.0....
Message-Id: <DD5655C5-8C15-44D6-9A8C-A58A96E58887@apache.org>
Date: Tue, 3 Sep 2013 13:09:48 -0400
To: "dev@cxf.apache.org" <dev@cxf.apache.org>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))


I'd like to get rid of the 3 big bundles for 3.0 and want to get other's =
thoughts=85.

Basically, I little history behind them=85..

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. =20=


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. =20

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.  =20

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=85) 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.  =20

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=85=20

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?

--=20
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com