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&amp;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>
 


Reply via email to