Re: What is the purpose of camel-core-xml? Move the code to camel-core?
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 code based on INSERT FAVORITE IDE behavior, Camel is getting to be an old and established project, the quotation marks here just since oss moves fast. :) It is sometimes frustrating to have to sit with customers when most of my replies simply are, yes - upgrade :) I spend pretty much every day nowadays on the road helping people solve problems with camel, integrate systems and with the fixes that went into 2.8, it is a pretty darn stable library, we had a few last integrations fixes on class loading with patches from Gert, that I think solved a majority of potential AMQ object marshaling issues, I'd much rather push API changes towards more modularity, optional usage but... We really are getting bigger, so breaking an API is something that will tick people of. I'm not sure I'd describe Camel core as bloated, I'd possibly say there are some interesting things in there, as an evolutionary process and example of evolution; I often hold Camels SPI/Osgi loading and inheritance model which shows in things like JMX as a way of how you can write things in a pretty nice modular way. Just my 0.1.. On Wed, Aug 31, 2011 at 11:51 PM, Christian Schneider ch...@die-schneider.net wrote: 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 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.netwrote: 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
Re: What is the purpose of camel-core-xml? Move the code to camel-core?
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 viewpoint from the biggest asset we have, the point of view from the community. So I put on a end user community hat. The people in the community look at Apache Camel as a great project to help make integration easier and quicker. They see the project as established and old as Johan put it. Camel 2.x is 2+ years old, and we are to do the 10th minor release (2.9). What people in the community say, and what I hear is that they, after the first couple of Camel 2.x releases. The API stabilized and they would be able to have fairly easy upgrades and being able to reuse existing components, and whatnot. As an end user you want to be able to reply on Apache Camel staying as is. For end users its pain and time consuming and cost a lot of $$$ and resources if they would need to recompile and adjust components and other adjustments due API changes in the core. We all know that rigors testing is often required for any changes like that to be accepted in a production environment. So its far better if the can keep using already existing without any recompilations. That is why we keep the API in camel-core stable. Yes there are classes in the core which could have a better name. Or be moved to another package etc. But we *keep them there*. The community want this. In all fairness they actually dont give a damn if TimeoutMap is in util package, what matters for them is that TimeoutMap is kept in that package in 2.x. Designing an API is much harder than you would think. One day you think and feel the API should be like X, then 2 days later you think that it should be like Y etc. Just look at the @ManagedXXX annotations. And what should a new package be named. What about this class, should it be named X instead of Y etc, because it have grown since its initial start etc? Designing APIs is much better for a new major release where you have the luxury of time and being able to cut milestone releases, and have feedback from early adaptors and keen end users who want to try out and help. Also its more accepted in the early releases (3.0, 3.1 and possible 3.2) to be a bit more open to API changes that it would in later releases. Especially now when we have Camel 2.x which is 2+ years. And for Camel 2.x is really taking up and being a very popular project. So we have grown and have a very large user base. And people use Camel in all kind of environments and systems, that we only have heard a tip of the iceberg. Besides regular end users, there is many open source projects and commercial vendors who use Camel as part of the offerings. They use pieces of the API which normal end users dont use as often. In fact this is also a very important perspective of the success of this project and community. That commercial vendors is integrating their products with Apache Camel. For example there are vendors who build management and monitoring apps, cloud infrastructure, commercial ESBs, IDE tooling, and whatnot. Popular open source projects such as Activiti, Akka, JBoss Drools, Smooks and others also rely on Camel is stable. So end users can use their products without them having pain to upgrade and recompile their products. Another concern of mine is that API changes was done after 2+ years and without any prior discussion and consensus from the Camel team. Likewise there has been absolutely no indicators from the community that they would like API changes in the core at this point in time. Again I have said many times Camel 2.x is 2+ years old, and the API needs to be stable. What would have been a better approach would be to start a thread about Camel 3.0, and one of the first goals would be API changes and looking at how to split the camel-core into smaller pieces, if that is feasible and makes sense. Then a branch in svn could have been setup. And for example Christian could experiment there and gets fingers dirty and thus be able to help sketch up a solid draft in the wiki for the Camel 3.0 API. Then when time is right, I guess that would then be soon, we could start on Camel 3.0 officially and get the API in place with a couple of milestone releases. When the 3.0 API is more set in stone, then we could look at the gap to 2.x, and then if possible. start adding @deprecated in there, in case it would be possible to help the 2.x users towards the 3.0 API without any backwards breaking. That said, it would IMHO, be a goal of the 3.0 API to be as compatible with 2.x which would make sense. We have a very large user based on 2.x, and it would be a shame to loose them because 3.0 is too different. Another concern is that I dont think *we* (I say we, as are of us from the Camel team) did this professionally. For example would never see such
Re: What is the purpose of camel-core-xml? Move the code to camel-core?
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 which changes will really hit people and make their migration more difficult. Currently we can not really predict that. So my proposal as I also stated in the release not is that we show people the changes and then ask for feedback if there are changes that really give them problems. In that case we can rollback these changes in a fix release or introduce more compatibility classes that help people. Instead of a bugfix release we could also introduce a release candidate for the 2.9 release and ask for feedback even before the 2.9.0. So I am quite sure we can make peoples experience quite smooth even with the changes. I still think that it is good to have these changes already in 2.9.0. There are two reasons for that. First we get much quicker feedback if changes are good. The 3.0 will take quite long and most users will only look at it when it is finished. Second we make our own life easier when we have to backport fixes from 3.0 to 2.9.x as 2.9 is much more similar to 3.0 than 2.8. The problem with holding back changes for a major release makes the change very big. This means it takes even longer to create the major release and as it is only tested after it is released it is very difficult to really get it right. As you said design is very difficult and I also often change my opinion how things work best. So it is very important to have early feedback. So my goal was to already ship the smaller changes in 2.9 and keep the bigger stuff for 3.0. Of course as you said we will even want 3.0 to be as compatible as possible while making the necessary changes to be ready for the future. In any case the good thing is that I think I did not have to do big changes to the examples during my refactorings. So I guess it is quite possible that most end users will not see any big changes when they upgrade. Christian Am 02.09.2011 08:52, schrieb Claus Ibsen: 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 viewpoint from the biggest asset we have, the point of view from the community. So I put on a end user community hat. The people in the community look at Apache Camel as a great project to help make integration easier and quicker. They see the project as established and old as Johan put it. Camel 2.x is 2+ years old, and we are to do the 10th minor release (2.9). What people in the community say, and what I hear is that they, after the first couple of Camel 2.x releases. The API stabilized and they would be able to have fairly easy upgrades and being able to reuse existing components, and whatnot. As an end user you want to be able to reply on Apache Camel staying as is. For end users its pain and time consuming and cost a lot of $$$ and resources if they would need to recompile and adjust components and other adjustments due API changes in the core. We all know that rigors testing is often required for any changes like that to be accepted in a production environment. So its far better if the can keep using already existing without any recompilations. That is why we keep the API in camel-core stable. Yes there are classes in the core which could have a better name. Or be moved to another package etc. But we *keep them there*. The community want this. In all fairness they actually dont give a damn if TimeoutMap is in util package, what matters for them is that TimeoutMap is kept in that package in 2.x. Designing an API is much harder than you would think. One day you think and feel the API should be like X, then 2 days later you think that it should be like Y etc. Just look at the @ManagedXXX annotations. And what should a new package be named. What about this class, should it be named X instead of Y etc, because it have grown since its initial start etc? Designing APIs is much better for a new major release where you have the luxury of time and being able to cut milestone releases, and have feedback from early adaptors and keen end users who want to try out and help. Also its more accepted in the early releases (3.0, 3.1 and possible 3.2) to be a bit more open to API changes that it would in later releases. Especially now when we have Camel 2.x which is 2+ years. And for Camel 2.x is really taking up and being a very popular project. So we have grown and have a very large user base. And people use Camel in all kind of environments and systems, that we only have heard a tip of the iceberg. Besides regular end users, there is many open source
Re: What is the purpose of camel-core-xml? Move the code to camel-core?
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 by shoving camel-core-xml in there :). For someone so keen to try enforce rules, he's broke his modularity rule already :) 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. Agreed. Though having a bigger jar as an option (say camel-core + camel-core-xml + camel-spring) could be handy for folks who use camel + spring together alot. Its less of an issue in the osgi world with features though. Anyway, I'd suggest leaving camel-core-xml the way it is and tackle that in 3.0. Agreed. We should be careful to keep 2.x of Camel nice and stable from an API perspective; but we can experiment in 3.x for sure. 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 seem that big a deal IMHO; the bean / file stuff isn't that big. -- James --- FuseSource Email: ja...@fusesource.com Web: http://fusesource.com Twitter: jstrachan, fusenews Blog: http://macstrac.blogspot.com/ Open Source Integration and Messaging
Re: What is the purpose of camel-core-xml? Move the code to camel-core?
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 seem that big a deal IMHO; the bean / file stuff isn't that big. I actually use Camel without using JMX, beans or files. But I'm maybe not a typical user. Not sure about the use of the term out of the box here. Right now the entire Camel package is available as a single download, including all components. Assuming one unpacks the whole thing at once, any component without external dependencies should work out of the box, and it shouldn't matter whether it's part of the core or not. Out of the box should only be an issue when someone has a particular need, such as a desire to shave off every byte one can. That's when one starts selectively importing jars, unpacking and rebuilding manifests and other fun stuff. Otherwise it shouldn't matter if the core was one piece or five, as long as all pieces were there. FWIW I agree that cleaving the core and restructuring the API is better earmarked for 3.0. Major releases are a good context for major changes. Perhaps the majority of users will adopt 3.0 before the release of 2.9.15. Don
Re: What is the purpose of camel-core-xml? Move the code to camel-core?
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 separated. They are highly entangled. For example the file component. You would expect that the file component knows about the api but the rest of core does not know about the file component. In reality the GenericFile class was used in several places outside the file component. So the core had knowledge about file component internals. In the case of the file component it was wasy to change that. The other components are similar. The bean component is the worst example. The connections between bean component classes and core are many and complicated and I am not yet sure how to solve that one. So these are just two example there are many more. The problem with camel-core is not the size. The problem is that it is not nicely separated logically. If the parts of the core had minimal dependencies among each other then camel-core would be much easier to use and change and also to test. So the minimal thing we need is a real architecture people know and agree with - with rules that make sure that things keep manageable. Splitting the core would be the easiest way to make the rules visible but it is not the only way to go. Your example of the mock component shows the problem nicely. It uses the core but is also used to test the core. This is in fact a problem. As soon as we have a camel-api the mock component can only depend on the api. Then the core can depend on api and on mock for testing. That will then make it nicely spearated. We can then still create a big jar in the build for beginners to give them an easy start but logically the parts of camel-core need to be nicely separated. Christian Am 31.08.2011 21:26, schrieb Claus Ibsen: 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 does not belong in camel-core, as it adds dependency and features which the camel-core does not need. Only the XML DSL capable components need those pieces and thus they are in their own module. Those modules is not testable unless you use camel-spring or camel-blueprint, and hence you would end up with code in the camel-core which cannot be tested. But frankly I think you are out of line and being disrespectful to the project, the community, and the people who have worked hard on this project. I would never call the camel-core bloated in any negative way as you do. 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. The camel-core has grown 200kb in 2.9 due that Google Code Map we embed directly now, for improving concurrency issues with the endpoint registry. 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. It is not strange. It was discussed and designed in the past. We worked together with OSGi experts such as gnodet. And Johan on the blueprint pieces etc. We have two such modules: camel-core-xml camel-core-osgi is core module for XML DSL and for running Camel in OSGi frameworks. It just happens to be that both camel-spring and camel-blueprint uses both of these two as - camel-spring has a XML DSL and supports both plain Spring as well as Spring-DM - camel-blueprint has a XML DSL and support OSGi blueprint. And thus we have shared and common code for those 2 components in the camel-core-XXX components. 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. That is still to be decided. And to be discussed later when Camel 3.0 is starting to take form. Christian Am 31.08.2011 17:54, schrieb Claus Ibsen: On Wed, Aug 31, 2011 at 5:51 PM, Christian Schneider ch...@die-schneider.netwrote: 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,
Re: What is the purpose of camel-core-xml? Move the code to camel-core?
+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 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 separated. They are highly entangled. For example the file component. You would expect that the file component knows about the api but the rest of core does not know about the file component. In reality the GenericFile class was used in several places outside the file component. So the core had knowledge about file component internals. In the case of the file component it was wasy to change that. The other components are similar. The bean component is the worst example. The connections between bean component classes and core are many and complicated and I am not yet sure how to solve that one. So these are just two example there are many more. The problem with camel-core is not the size. The problem is that it is not nicely separated logically. If the parts of the core had minimal dependencies among each other then camel-core would be much easier to use and change and also to test. So the minimal thing we need is a real architecture people know and agree with - with rules that make sure that things keep manageable. Splitting the core would be the easiest way to make the rules visible but it is not the only way to go. Your example of the mock component shows the problem nicely. It uses the core but is also used to test the core. This is in fact a problem. As soon as we have a camel-api the mock component can only depend on the api. Then the core can depend on api and on mock for testing. That will then make it nicely spearated. We can then still create a big jar in the build for beginners to give them an easy start but logically the parts of camel-core need to be nicely separated. Christian Am 31.08.2011 21:26, schrieb Claus Ibsen: 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 does not belong in camel-core, as it adds dependency and features which the camel-core does not need. Only the XML DSL capable components need those pieces and thus they are in their own module. Those modules is not testable unless you use camel-spring or camel-blueprint, and hence you would end up with code in the camel-core which cannot be tested. But frankly I think you are out of line and being disrespectful to the project, the community, and the people who have worked hard on this project. I would never call the camel-core bloated in any negative way as you do. 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. The camel-core has grown 200kb in 2.9 due that Google Code Map we embed directly now, for improving concurrency issues with the endpoint registry. 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. It is not strange. It was discussed and designed in the past. We worked together with OSGi experts such as gnodet. And Johan on the blueprint pieces etc. We have two such modules: camel-core-xml camel-core-osgi is core module for XML DSL and for running Camel in OSGi frameworks. It just happens to be that both camel-spring and camel-blueprint uses both of these two as - camel-spring has a XML DSL and supports both plain Spring as well as Spring-DM - camel-blueprint has a XML DSL and support OSGi blueprint. And thus we have shared and common code for those 2 components in the camel-core-XXX components. 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. That is still to be decided. And to be discussed later when Camel 3.0 is starting to take form. 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
Re: What is the purpose of camel-core-xml? Move the code to camel-core?
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 -- -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com -- Claus Ibsen - FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
Re: What is the purpose of camel-core-xml? Move the code to camel-core?
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 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
Re: What is the purpose of camel-core-xml? Move the code to camel-core?
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 -- Claus Ibsen - FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
Re: What is the purpose of camel-core-xml? Move the code to camel-core?
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.netwrote: 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
Re: What is the purpose of camel-core-xml? Move the code to camel-core?
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 does not belong in camel-core, as it adds dependency and features which the camel-core does not need. Only the XML DSL capable components need those pieces and thus they are in their own module. Those modules is not testable unless you use camel-spring or camel-blueprint, and hence you would end up with code in the camel-core which cannot be tested. But frankly I think you are out of line and being disrespectful to the project, the community, and the people who have worked hard on this project. I would never call the camel-core bloated in any negative way as you do. 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. The camel-core has grown 200kb in 2.9 due that Google Code Map we embed directly now, for improving concurrency issues with the endpoint registry. 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. It is not strange. It was discussed and designed in the past. We worked together with OSGi experts such as gnodet. And Johan on the blueprint pieces etc. We have two such modules: camel-core-xml camel-core-osgi is core module for XML DSL and for running Camel in OSGi frameworks. It just happens to be that both camel-spring and camel-blueprint uses both of these two as - camel-spring has a XML DSL and supports both plain Spring as well as Spring-DM - camel-blueprint has a XML DSL and support OSGi blueprint. And thus we have shared and common code for those 2 components in the camel-core-XXX components. 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. That is still to be decided. And to be discussed later when Camel 3.0 is starting to take form. 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 -- Claus Ibsen - FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
Re: What is the purpose of camel-core-xml? Move the code to camel-core?
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 entire Felix framework, including the documentation. The camel-core jar represents two-thirds of the volume of my deployed Felix OSGI application. Yes, the core does a lot, but how many people genuinely use all the features and built-in components? Not that I'm necessarily advocating splitting it into all separate modules, since it would probably take up more space that way, what with the extra manifests and activators and all. But still, even if not bloated, I might call it non-trivially sized. Don
Re: What is the purpose of camel-core-xml? Move the code to camel-core?
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 the project a success it is today. In all fairness, 1.6 mb is bigger than the entire Felix framework, including the documentation. The camel-core jar represents two-thirds of the volume of my deployed Felix OSGI application. In all fairness you are comparing apples to oranges. Is it not a goal for the Felix project to be a micro container and very small, and being embeddable into small devices and whatnot. Thats not necessarily the same goal for Camel. Instead you ought to compare Camel with equal projects such as - Spring Integration - Apache Synapse - Mule - and possible others Spring Integration is about 500kb. But then you must use Spring Framework also. So thats about 2-3mb extra, depending on your choice of their JARs. Apache Synpase has a ton of JARs. I am actually not aware which one is the bare you need to run. The dist is 40+mb. Mule is about the same story as Synapse. However Mule is designed to be an ESB and thus bigger. But the Mule people also like to compare against Camel and say they can embed and run Mule standalone, or in WARs etc. Mule and OSGi, well we all may know what Ross said about that. Yes the camel-core could be splitted up but it may just add more confusion and trouble to the mix. We got a lot of new and less experienced users to Apache Camel, as they need help with integration. So for them being able to pick camel-core and be able to run out of the box is great. They dont need to fiddle with adding 8-15 JARs as you would do when using Spring or other which have fine grained JARs for the project. The 1.6 - 1.7mb in camel-core is roughly taking up space as follows - default implementation = 500kb - model = 400kb - eips = 400kb - components = 300kb - jmx = 100kb - other stuff = the rest In the components there is 3 which take up some size - bean, file and mock The rest of the components is minimal, some one one class, and others maybe 10-20kb The bean component is a core piece of camel and ought to be in camel-core. Mock is used heavily for unit testing camel itself. But also for end users as well. It could be moved to camel-mock, but then we would need to build camel-mock before camel-core to be able to test camel-core. Would that not cause trouble, as camel-mock depends on camel-core? Then file is not, and could be in a camel-file JAR. But then again when people get started with Camel they often try out with files. So having that work out of the box is nice. And for management, Christian have prepared the API for that. And it would be possible to split that out in camel-core-management or what a component name could be for the future. If it makes sense. So the big pieces to split Camel would be the eips and the model. But those are key concepts for Camel. The routing and EIPs. Yes, the core does a lot, but how many people genuinely use all the features and built-in components? Not that I'm necessarily advocating splitting it into all separate modules, since it would probably take up more space that way, what with the extra manifests and activators and all. But still, even if not bloated, I might call it non-trivially sized. Don -- Claus Ibsen - FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
Re: What is the purpose of camel-core-xml? Move the code to camel-core?
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 Whytockdwhyt...@gmail.com wrote: On Wed, Aug 31, 2011 at 3:26 PM, Claus Ibsenclaus.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 entire Felix framework, including the documentation. The camel-core jar represents two-thirds of the volume of my deployed Felix OSGI application. In all fairness you are comparing apples to oranges. Is it not a goal for the Felix project to be a micro container and very small, and being embeddable into small devices and whatnot. Thats not necessarily the same goal for Camel. Instead you ought to compare Camel with equal projects such as - Spring Integration - Apache Synapse - Mule - and possible others Spring Integration is about 500kb. But then you must use Spring Framework also. So thats about 2-3mb extra, depending on your choice of their JARs. Apache Synpase has a ton of JARs. I am actually not aware which one is the bare you need to run. The dist is 40+mb. Mule is about the same story as Synapse. However Mule is designed to be an ESB and thus bigger. But the Mule people also like to compare against Camel and say they can embed and run Mule standalone, or in WARs etc. Mule and OSGi, well we all may know what Ross said about that. Yes the camel-core could be splitted up but it may just add more confusion and trouble to the mix. We got a lot of new and less experienced users to Apache Camel, as they need help with integration. So for them being able to pick camel-core and be able to run out of the box is great. They dont need to fiddle with adding 8-15 JARs as you would do when using Spring or other which have fine grained JARs for the project. The 1.6 - 1.7mb in camel-core is roughly taking up space as follows - default implementation = 500kb - model = 400kb - eips = 400kb - components = 300kb - jmx = 100kb - other stuff = the rest In the components there is 3 which take up some size - bean, file and mock The rest of the components is minimal, some one one class, and others maybe 10-20kb The bean component is a core piece of camel and ought to be in camel-core. Mock is used heavily for unit testing camel itself. But also for end users as well. It could be moved to camel-mock, but then we would need to build camel-mock before camel-core to be able to test camel-core. Would that not cause trouble, as camel-mock depends on camel-core? Then file is not, and could be in a camel-file JAR. But then again when people get started with Camel they often try out with files. So having that work out of the box is nice. And for management, Christian have prepared the API for that. And it would be possible to split that out in camel-core-management or what a component name could be for the future. If it makes sense. So the big pieces to split Camel would be the eips and the model. But those are key concepts for Camel. The routing and EIPs. Yes, the core does a lot, but how many people genuinely use all the features and built-in components? Not that I'm necessarily advocating splitting it into all separate modules, since it would probably take up more space that way, what with the extra manifests and activators and all. But still, even if not bloated, I might call it non-trivially sized. Don
Re: What is the purpose of camel-core-xml? Move the code to camel-core?
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.netwrote: 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
Re: What is the purpose of camel-core-xml? Move the code to camel-core?
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 without any pain, that is amazing impression of Camel. I'm still OK if it is less then 3M. On 9/1/11 4:15 AM, Donald Whytock wrote: On Wed, Aug 31, 2011 at 3:26 PM, Claus Ibsenclaus.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 entire Felix framework, including the documentation. The camel-core jar represents two-thirds of the volume of my deployed Felix OSGI application. Yes, the core does a lot, but how many people genuinely use all the features and built-in components? Not that I'm necessarily advocating splitting it into all separate modules, since it would probably take up more space that way, what with the extra manifests and activators and all. But still, even if not bloated, I might call it non-trivially sized. Don -- Willem -- FuseSource Web: http://www.fusesource.com Blog:http://willemjiang.blogspot.com (English) http://jnn.javaeye.com (Chinese) Twitter: willemjiang Weibo: willemjiang
Re: What is the purpose of camel-core-xml? Move the code to camel-core?
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 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.netwrote: 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 -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: What is the purpose of camel-core-xml? Move the code to camel-core?
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* 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.netwrote: 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 -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
