Author: buildbot Date: Tue Jan 22 04:19:22 2013 New Revision: 847503 Log: Production update by buildbot for camel
Modified: websites/production/camel/content/cache/main.pageCache websites/production/camel/content/camel-30-ideas.html Modified: websites/production/camel/content/cache/main.pageCache ============================================================================== Binary files - no diff available. Modified: websites/production/camel/content/camel-30-ideas.html ============================================================================== --- websites/production/camel/content/camel-30-ideas.html (original) +++ websites/production/camel/content/camel-30-ideas.html Tue Jan 22 04:19:22 2013 @@ -79,14 +79,14 @@ <div class="panelMacro"><table class="warningMacro"><colgroup span="1"><col span="1" width="24"><col span="1"></colgroup><tr><td colspan="1" rowspan="1" valign="top"><img align="middle" src="https://cwiki.apache.org/confluence/images/icons/emoticons/forbidden.gif" width="16" height="16" alt="" border="0"></td><td colspan="1" rowspan="1"><b>WIP</b><br clear="none"></td></tr></table></div> -<p>This is a roadmap which details the overall and major goals for Camel 3.0. Fell free to discuss this at the Camel <a shape="rect" href="mailing-lists.html" title="Mailing Lists">Mailing Lists</a> if you have ideas or feedback.</p> +<p>Camel is now almost 6 years old and its second revision camel-2.x is more than 4.5 years old already. Camel is extremely mature, used in production by a large number of organizations from small to large and even governments. We feel like we really hit the initial target of simplifying integration. Camel's middleware abstraction api and the eip based routing brought a lot of positive feedback from users.</p> -<p>The Camel PMC conducted a <a shape="rect" href="camel-30-ideas.data/camel-survey-2010.pdf?version=1&modificationDate=1291051405000">survey in Oct 2010</a> to get a better understanding of how Camel is used and what the priorities for Camel 3.0 should be.</p> +<p>There is however more that could be done to simplify the work of integration developers who need new components (not shipped with camel for licensing - copyleft of commercial - or other reasons) or new integration patterns or algorithms or even new tools. We learned a lot in the past years and benefited from a strong and continuously growing community. It's time to put what we learned to good use and re-engineer your favourite integration framework yet again.</p> -<div class="panelMacro"><table class="warningMacro"><colgroup span="1"><col span="1" width="24"><col span="1"></colgroup><tr><td colspan="1" rowspan="1" valign="top"><img align="middle" src="https://cwiki.apache.org/confluence/images/icons/emoticons/forbidden.gif" width="16" height="16" alt="" border="0"></td><td colspan="1" rowspan="1"><b>Nothing is committed/confirmed</b><br clear="none">The items listed on this wiki page is just <b>ideas</b> for the roadmap. Anything is subject for change.<br clear="none"> -Speak up if you want to ensure a feature is on the roadmap, or if you have new ideas etc. +<p>The middleware abstractions look pretty solid, and aside from some possible reshuffling we don't expect major changes. As a consequence, most of the components will retain the same general feel. The core will however be rearchitected to become even more pluggable and modular. We will however spare no effort to make a new Camel 3 be as backward compatible as possible and when not possible at least provide a painless migration path.</p> + +<p>This is a mindmap of ideas for improving Camel 3.0. Fell free to discuss this on the Camel <a shape="rect" href="mailing-lists.html" title="Mailing Lists">Mailing Lists</a> if you have other ideas or feedback.</p> -<p>When development of Camel 3.0 starts we will update status here which items have been implemented in the source code, and which have been discarded/deferred etc.</p></td></tr></table></div> <h3><a shape="rect" name="Camel3.0-Ideas-ClearerArchitectureofCamelCore"></a>Clearer Architecture of Camel Core</h3> @@ -96,9 +96,12 @@ Speak up if you want to ensure a feature <p>So why should this be important? Currently components depend on camel-core as a whole and there are no further rules which classes the components should use and which classes should be private to core. Even classes from the impl package are needed. So this means that any refactoring we do in camel core could affect all components. As camel is growing steadily this can become quite problematic.</p> -<p>Split camel-core into three parts:</p> +<h4><a shape="rect" name="Camel3.0-Ideas-Improvethetestapifortestingcomponents%28hadrian%29"></a>Improve the test api for testing components (hadrian)</h4> +<p>No matter what choices and changes we make in the core, many tests in components will start failing. That is because virtually all unit tests in components test much more than the component itself, by setting up routes, etc. A simple thing would be do create something like xyzTestSupport (where xyz in {"Component", "Configuration", "Endpoint", "Producer", "Consumer", "Language", etc... }), that test a respective area without setting up routes and possibly use a minimal CamelContext (w/o component discover and/or other features). Moving component unit tests to such a framework is not complicated, a bit tedious, but hopefully we'll benefit (yet again) from community contributions and gain new committers in the process. This is probably the first thing that should be done that will allow us to be more productive with the other improvements. It can also be done in 2.x and won't require any incompatible changes.</p> + +<h4><a shape="rect" name="Camel3.0-Ideas-Splitcamelcoreintomultipleparts%28champion%3F%29"></a>Split camel-core into multiple parts (champion?)</h4> +<ul><li>api</li><li>dsl/builder</li><li>impl</li><li>...</li></ul> -<p>api, builder, impl</p> <p>These should be structured in a way that these big building blocks do not have cyclic dependencies. Any other cycles can be ignored in this step.</p>