You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Daniel Kulp <dk...@apache.org> on 2013/09/03 19:09:48 UTC
[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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
RE: [DISCUSS] Big bundles for 3.0....
Posted by Andrei Shakirin <as...@talend.com>.
+1 from me, it is a bit confusing at the moment.
Regards,
Andrei.
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: Dienstag, 3. September 2013 19:10
> To: dev@cxf.apache.org
> 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
> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
> http://coders.talend.com
Re: [DISCUSS] Big bundles for 3.0....
Posted by Sergey Beryozkin <sb...@gmail.com>.
+1.
One thing I've found recently is that I'm always concerned that I have
to update all 3 big bundles to make sure the new modules I may be adding
make it into them :-),
I guess we may still want to keep a large cxf.jar in the distro for
people not working with Maven, but these big bundles do not give us much
now with fewer dependencies throughout and Maven downloading what is needed
Cheers, Sergey
On 03/09/13 18: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?
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: [DISCUSS] Big bundles for 3.0....
Posted by Freeman Fang <fr...@gmail.com>.
+1 for doing it in 3.0
－－－－－－－－－－－－－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
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
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
Re: [DISCUSS] Big bundles for 3.0....
Posted by Christian Schneider <ch...@die-schneider.net>.
+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