SInce I work pretty much 97.98% in osgi, I'll weigh in and say that I really
like this.
If XML is only used from Blueprint / Spring-DM, we provide those with the
features descriptors,
they import nothing - i.e. are model/api bundles, why make a jar bigger?
I really don't think we should refactor
Hi
At first I will say that when I replied to this it was late in the
evening, so I may not have been able to
pickup the correct words, when I wrote the mail. The tone was due
strong concerns what has
happened over the last period to the API in camel-core.
The following I write with the
Hi Claus,
it is great that you wear the community hat. This is a needed balance to
my refactorings that are of course rather architecture focused.
The good thing is that thanks to your comments many changes are now more
compatible than I originally did them.
So of course the big question is
On 1 September 2011 02:01, Hadrian Zbarcea hzbar...@gmail.com wrote:
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.
But he was suggesting making camel-core bigger adding in more
dependencies
On Fri, Sep 2, 2011 at 6:41 AM, James Strachan ja...@fusesource.com wrote:
I'm also not sure how much smaller we can really get camel-core; since
out of the box you'd assume camel can work with JMX, beans, files
implement the patterns and have the model in there. Shaving off
20-100k doesn't
Hi Claus,
I did not intend to be disrespectful. It is natural that things become
bloated when a project grows. In fact it is very difficult to avoid.
So I think camel-core is too complex. That does not mean it is too big
in size. Even more important is that the parts of the core are not
+1 for Camel API part, in this way we can let camel-core and
camel-spring test with single camel test framework.
But I think this change should be part of Camel 3.0, as it is not small
piece of cake :)
On 9/1/11 2:06 PM, Christian Schneider wrote:
Hi Claus,
I did not intend to be
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
That sounds to me like it would fit nicely in camel-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.
Christian
Am 31.08.2011 17:43, schrieb Claus Ibsen:
On
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
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
On Wed, Aug 31, 2011 at 7:45 PM, Christian Schneider
ch...@die-schneider.net wrote:
The camel-core is already bloated anyway. I see no reason to not include
those classes.
I may have posted the bloated word before which would be overstating
what I meant. What I was to say
is that camel-core-xml
On Wed, Aug 31, 2011 at 3:26 PM, Claus Ibsen claus.ib...@gmail.com wrote:
The core is 1.6mb which is not bloated. In fact with the core you can
do really a lot with Camel, which impress
a lot of people, and help make the project a success it is today.
In all fairness, 1.6 mb is bigger than the
On Wed, Aug 31, 2011 at 10:15 PM, Donald Whytock dwhyt...@gmail.com wrote:
On Wed, Aug 31, 2011 at 3:26 PM, Claus Ibsen claus.ib...@gmail.com wrote:
The core is 1.6mb which is not bloated. In fact with the core you can
do really a lot with Camel, which impress
a lot of people, and help make
In all fairness, it's becoming more and more bloated, alright. Donald
was right to point it out too and did it in a very nice way. He was not
comparing apples and oranges.
My $0.02,
Hadrian
On 08/31/2011 05:14 PM, Claus Ibsen wrote:
On Wed, Aug 31, 2011 at 10:15 PM, Donald
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.
camel-core doesn't have any third part dependencies (only slf4j).
But the whole camel project may have 450M third part dependency as it
out of our control.
I think camel-core has some built-in components and EIP implementation
helps user to start up a simple EIP journey by using a 1.6M tool
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
Yes that is a good thing to do in 3.0. I just wanted to discuss and try
to have an agreement to do it at some point.
Christian
Am 01.09.2011 03:01, schrieb Hadrian Zbarcea:
Personally, I don't think we need a big jar. My understanding is that
Christian is looking for ways to *improve*
19 matches
Mail list logo
