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 changes from professional products such as Spring Framework. Which has become a key infrastructure in many organizations. It would be great for Apache and the Camel community, that Camel 2.x (could become / already is) key in their integration needs. Okay I really didnt mean to write a long email, as we all have alot to do in our daily work and lives. One last point. I am not trying to be the devils advocate. But from a community point of view. They would possible like that all the API changes would be rolled back. No API changes in an "old" product is what they wish for. However what is done is done. I will lobby for that we do not repart this in the future. Okay I take of the "community hat". I guess there were a few parts which had the "Camel team hat". Okay good weekend. And no hard feelings. We are all working in the interrest of the community. On Thu, Sep 1, 2011 at 8:06 AM, Christian Schneider <ch...@die-schneider.net> 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 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 > > -- 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/
