svn commit: r847704 - in /websites/production/camel/content: cache/main.pageCache camel-30-ideas.html

[bu...@apache.org]

Author: buildbot
Date: Wed Jan 23 22:18:22 2013
New Revision: 847704

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 Wed Jan 23 22:18:22 2013
@@ -97,9 +97,15 @@
 <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>
 
 <h4><a shape="rect" name="Camel3.0-Ideas-Improvethetestapifortestingcomponents%28hadrian%29"></a>Improve the test api for testing components (hadrian)</h4>
+<h5><a shape="rect" name="Camel3.0-Ideas-Endorsements"></a>Endorsements</h5>
+<p>+1: cmueller</p>
+
 <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>
+<h5><a shape="rect" name="Camel3.0-Ideas-Endorsements"></a>Endorsements</h5>
+<p>+1: cmueller</p>
+
 <ul><li>api</li><li>dsl/builder</li><li>impl</li><li>...</li></ul>