camel-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r847503 - in /websites/production/camel/content: cache/main.pageCache camel-30-ideas.html
Date Tue, 22 Jan 2013 04:19:22 GMT
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>
 



Mime
View raw message