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>