I'd like to amplify one of the comments by Claus about slimming the core of
camel and making other components less dependent on it.
I'd like to see the core limited to compile time dependencies - annotations,
interfaces and factories only. The runtime engine might be blueprint,
spring, or whatever.
A maven project file might look like:
<dependencies>
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-core</artifactId>
</dependency>
....
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>spring-engine</artifactId>
<scope>test</scope>
</dependency>
Then the specified engine would also need to be present through whatever
bootstrap mechanism whether in Spring, Karaf or whatever.
This would also make for a unified test structure during Camel 3
development. The same set of acceptance tests should run against any of the
engines since they'd be running against the Camel core API/factories and not
explicitly running against the engines themselves. In other words, the
engines should be firmly hidden behind the facades of the core.
In a way it would be the way that JDBC is supposed to work but Apache Camel
group would have full control over the compliance. If the acceptance tests
run against all of the engines then things are fine. If a test fails when
an engine is swapped in then the engine implementation has to be fixed or
dealt with in some fashion.
If someone later on wants to develop a new engine with a new
framework/library there would be a standard set of acceptance tests keyed to
the core bundle that the engine would have to pass. This would make for
easy expansion to other frameworks in the future that may yet to be invented
or that are just coming into acceptance now.
--
View this message in context:
http://camel.465427.n5.nabble.com/Camel-3-tp5777217p5777219.html
Sent from the Camel Development mailing list archive at Nabble.com.
