Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4E5F1D4E.2050403@die-schneider.net>
Date: Thu, 01 Sep 2011 07:51:10 +0200
From: Christian Schneider <chris@die-schneider.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: dev@camel.apache.org
Subject: Re: What is the purpose of camel-core-xml? Move the code to
 camel-core?
References: <4E5E55DB.4060000@die-schneider.net>
 <CAGB5yNkAYZgt-_cr84krRy=7bK7Nrn3QfqN3diOsE8-2HcrVAA@mail.gmail.com>
 <4E5E5889.1000903@die-schneider.net>
 <CAGB5yNkfRVexqP2sTkcims6F50_rTeAR_UKZZbEFKEp7GKx=Cg@mail.gmail.com>
 <4E5E7333.4030704@die-schneider.net>
 <CAEQV+EGyuvMfW63pb3nqRmuUhd2WjjgUUm_BH2OshuM9mzZwbg@mail.gmail.com>
In-Reply-To: 
 <CAEQV+EGyuvMfW63pb3nqRmuUhd2WjjgUUm_BH2OshuM9mzZwbg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

camel-core-xml has only a bunch of classes. It adds not a single 
dependency.
So I think it could be added to core. We can also leave it in a separate 
jar but then it should be that .. a simple jar.
In the moment the camel-core-xml classes are directly imported into 
spring and blueprint projects. This makes the build process more 
complicated than
it needs to be and at least in Eclipse it causes additional problems.

Architecture is always balancing of requirements. So as it is a 
requirement to make camel easy to use for users but also to make it easy 
to use for developers of camel I think it is the best choide to move
camel-core-xml into the core.

The big jar option is not a bad idea. I think we could use this when we 
split camel-core to make it easier for beginners to start with camel.

Christian

Am 31.08.2011 21:45, schrieb Guillaume Nodet:
> 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
> <chris@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
>>> <chris@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
>>>>> <chris@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
>>
>>
>
>

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com