Camel 3

[Ranx <br...@mediadriver.com>]

Is there a discussion group or list or issue where Camel 3 features are being
discussed?  I've found this:

http://camel.apache.org/camel-30-ideas.html

I'd upvote the baseline of JDK 8.  By the time 3.0 becomes hardened it would
be a realistic baseline and it provides too many mechanisms for streaming
and looping.  TLS updates and upgrades in JDK 8 are also going to become
essential for any enterprise integration work.

One big one for me would a truly solid OSGi implementation.  No back door
classloading from the SU.  All OSGi testing based on Pax Exam simply because
it is a true container test.  

Unification of annotations.  That's a difficult one but annotations should
work the same whether in Spring, Blueprint, or whatever.  If not, then the
annotations should be marked and specified as specific to a given library. 

There are quite a few others that I can think of but this is probably not
the place to randomly post such notions.







--
View this message in context: http://camel.465427.n5.nabble.com/Camel-3-tp5777217.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: Camel 3

[Ranx <br...@mediadriver.com>]

Is this the wrong place for such discussions?



--
View this message in context: http://camel.465427.n5.nabble.com/Camel-3-tp5777217p5777295.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: Camel 3

[Ranx <br...@mediadriver.com>]

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.