Personally, I don't think we need a big jar. My understanding is that
Christian is looking for ways to *improve* modularity and reduce
dependencies. I am not a big fan of big fat jars (and my understanding
is that that is not what Christian proposed). Modularity is a key aspect
of Camel.
Anyway, I'd suggest leaving camel-core-xml the way it is and tackle that
in 3.0.
Hadrian
On 08/31/2011 03:45 PM, Guillaume Nodet wrote:
That's a modularity problem. If we want Camel to behave nicely in
OSGi (and that's not the only reason), we need to be modular, i.e.
have jars that can focus on one thing instead of having a single jar
with all dependencies being optional. It really helps managing
dependencies both internally and externally.
If you really want a big fat jar, we could consider building one in
addition to the small jars, kinda like what CXF does. There may be
use cases for that, but that does not mean it should be the only
packaging.
On Wed, Aug 31, 2011 at 19:45, Christian Schneider
<ch...@die-schneider.net> wrote:
The camel-core is already bloated anyway. I see no reason to not include
those classes.
The current mechanism of directly including the classes in camel-spring and
camel-blueprint is really strange and I think having some classes in core
that are not needed in some cases is much better then what we have now.
We will need to split the core anyway for 3.0 so reintegrating
camel-core-xml would reduce the number of jars again which is good.
Christian
Am 31.08.2011 17:54, schrieb Claus Ibsen:
On Wed, Aug 31, 2011 at 5:51 PM, Christian Schneider
<ch...@die-schneider.net> wrote:
That sounds to me like it would fit nicely in camel-core.
No as that is just bloat to the core.
Btw. is there a reason why camel-core-xml is scope provided in
camel-spring?
This gives me errors in some tests of other components in eclipse as
these
classes can not be found.
There is no problem at all in IDEA.
Yes one of the reasons is osgi. By having the camel-core-xml .class
files included directly into the camel-spring and camel-blueprint
wo dont have any osgi hickups due JAR files not being loaded and
whatnot. That was a pain in the past.
Christian
Am 31.08.2011 17:43, schrieb Claus Ibsen:
On Wed, Aug 31, 2011 at 5:40 PM, Christian Schneider
<ch...@die-schneider.net> wrote:
Hi all,
can someone tell me what the purpose of camel-core-xml is and why it
has
to
be a spearate project?
It does not seem to have any other dependencies than camel-core.
So if there is no good reason to keep it separate I propose to move
that
code into camel-core.
No.
Its an abstract component which has base classes used by XML DSLs such
as camel-spring and camel-blueprint.
This ensures that code is reused between the 2 XML DSLs and make it
easier to keep them in sync and whatnot.
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
