Hi Claus,
I first did not see the connection to camel-ftp. I now see that it is
necessary at the moment. I think there are simpler solutions though.
I will work out a proposal. Of coure this is not for camel 2.x. The
change would be too big.
Christian
Am 31.08.2011 21:34, schrieb Claus Ibse
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
sepa
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* modular
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.
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 wi
Comments inline,
Hadrian
On 08/31/2011 03:34 PM, Claus Ibsen wrote:
So what are your thoughts about that?
>
Camel 2.x should be kept backwards compatible and API stable.
We have end users who build custom components on top of the Camel file
component and rely on the API being as is.
That is on
Yes, I agree with that, reason why Registries that use caches *are* and
should stay as Services. The PropertyEditorTypeConverter in particular
doesn't need to be a Service, but the EndpointRegisty, ConsumerCache and
ProducerCache should be and are Services.
So you are correct about not leaving
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.
Anyw
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 Whytock wrote:
O
On Wed, Aug 31, 2011 at 10:15 PM, Donald Whytock wrote:
> On Wed, Aug 31, 2011 at 3:26 PM, Claus Ibsen 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.
[
https://issues.apache.org/jira/browse/CAMEL-4330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Liguori closed CAMEL-4330.
-
Resolution: Not A Problem
Closing this issue... no real need for it.
> add support for Aegis as
On Wed, Aug 31, 2011 at 3:26 PM, Claus Ibsen 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 entire Felix frame
I wonder if there wont be a problem when you shutdown camel, or run
Camel in a hot deployment environment.
As before the service would ensure start|stop callbacks, where we
could clear the caches when stopping.
That is now gone, which means we can just hope the GC eventually will
be able to reclai
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 a
On Wed, Aug 31, 2011 at 3:28 PM, Christian Schneider
wrote:
> Currently the file component uses a special message GenericFile to send
> files into camel routes.
> This is bad as several other parts of camel need to deal with this type. It
> is already a bit better now that I introduced WrappedFile
On Wed, Aug 31, 2011 at 7:45 PM, Christian Schneider
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 does not belong in
Hi,
Is it possible to merge CAMEL-3968 on the 2.8.1 branch to have it in the
2.8.1 release?
Best regards
Andi
--
View this message in context:
http://camel.465427.n5.nabble.com/DISCUSS-Apache-Camel-2-8-1-release-tp4733505p4755143.html
Sent from the Camel Development mailing list archive at Nabb
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 wha
[
https://issues.apache.org/jira/browse/CAMEL-4401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13094707#comment-13094707
]
David Tombs commented on CAMEL-4401:
A possible kludge-fix could be to compare() every
StreamResequencer poisoned by bad Exchange
--
Key: CAMEL-4401
URL: https://issues.apache.org/jira/browse/CAMEL-4401
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions:
[
https://issues.apache.org/jira/browse/CAMEL-4243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Liguori closed CAMEL-4243.
-
Resolution: Invalid
Supported EIPs continue to grow, so this is an ongoing effort that cannot
fe
On Wed, Aug 31, 2011 at 5:51 PM, Christian Schneider
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
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:40 PM, Christian Schneider
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
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.
Christian
--
--
Christi
[
https://issues.apache.org/jira/browse/CAMEL-4398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CAMEL-4398.
Resolution: Fixed
> Add profile to camel-core pom.xml to have tools.jar added as dependency which
[
https://issues.apache.org/jira/browse/CAMEL-4398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp reopened CAMEL-4398:
Assignee: Daniel Kulp (was: Claus Ibsen)
I have a better fix for this
The tools jar is r
[
https://issues.apache.org/jira/browse/CAMEL-4034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13094578#comment-13094578
]
Hadrian Zbarcea commented on CAMEL-4034:
@Ioannis, there are other files missing i
Consumer Endpoint for AWS SNS Service
-
Key: CAMEL-4400
URL: https://issues.apache.org/jira/browse/CAMEL-4400
Project: Camel
Issue Type: Improvement
Components: camel-aws
Reporter: Ka
Upgrade to maven-bundle-plugin 2.3.5 and remove not needed special camel
version for osgi manifest
--
Key: CAMEL-4399
URL: https://issues.apache.org/jira/browse/CAMEL-
[
https://issues.apache.org/jira/browse/CAMEL-4398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-4398.
Resolution: Not A Problem
We should upgrade the bundle plugin as it does not need the special versi
Currently the file component uses a special message GenericFile to send
files into camel routes.
This is bad as several other parts of camel need to deal with this type.
It is already a bit better now that I introduced WrappedFile as an
abstraction of GenericFile so other parts of camel do not h
[
https://issues.apache.org/jira/browse/CAMEL-4398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13094501#comment-13094501
]
Claus Ibsen commented on CAMEL-4398:
Sorry the issue is the tools JAR is added as dep
Documented the potentially incompatible changes in the release notes.
Christian
Am 31.08.2011 08:48, schrieb Claus Ibsen:
Hi
The API in camel-core have changed on trunk recently by the works of
Christian S.
I just to remind that its important to notice all the API breaking
changes in the API
Add profile to camel-core pom.xml to have tools.jar added as dependency which
is needed for CI servers
--
Key: CAMEL-4398
URL: https://issues.apache.org/jira/brows
Hi Claus,
thanks for reminding. Documenting the changes make a lot of sense of course.
Christian
Am 31.08.2011 08:48, schrieb Claus Ibsen:
Hi
The API in camel-core have changed on trunk recently by the works of
Christian S.
I just to remind that its important to notice all the API breaking
36 matches
Mail list logo
