camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen">
Subject RE: Roadmap after Camel 1.4 release
Date Wed, 23 Jul 2008 04:12:10 GMT

DSL Documentation:
- Yes it is definitely needed. For new users to Camel starting with the Java DSL can be a
bit troublesome to know how to use, after you got the hello logger here I am working with

1) We could add documentation to the javadoc (and use SNIPPET or some other tools to extract
it to the wiki). We are able to quickly determinate what DSL types we have documentation for
and not. Also the IDEs will be able to quick tooltip the javadoc for end-users.

2) We could add it to wiki. However it's harder to be sure that we got them all covered and
staying in-sync for the future, and that all options is documented as well.

3) How can we with tools get the documentation in the spring XSD as well? 

Med venlig hilsen
Claus Ibsen
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576

-----Original Message-----
From: Gert Vanthienen [] 
Sent: 22. juli 2008 14:44
Subject: Roadmap after Camel 1.4 release


Now that Camel 1.4 is out, we should probably take a look at the roadmap 
for Camel 1.5 and 2.0.  There are already quite a few issues planned for 
1.5 ([1]) and 2.0 ([2]).  Perhaps this is a good time to discuss the 
long-term goals and add issues for those to JIRA as well.  Chatting with 
James on IRC, he proposed we would focus on usability and tooling for 
the next release.  Personally, I would also like to finish up the Scala 
DSL and add a Maven archetype to allow people to really start using it, 
so we can ship our next release with 3 full-fledged DSLs.  Any other 

Whenever we start developing on Camel 2.0, we would have a great 
opportunity to remove some of the deprecated methods that we 
(re-)introduced with Camel 1.4 and do some other API breaking 
refactorings (like reducing code cycles, adding parameters to the 
TypeConverter methods -- e.g. for encoding, use verbs for the DSL, 
...).  With a new major release number, users expect these kind of 
changes, especially if we clearly add them to a migration guide in the 
release documents.  Are we going to do an intermediate 1.5 release (only 
deprecating methods as we move along) or will the next release be 2.0 
instead?  Do we need to create a branch for allowing bug fixes for 1.4 
to be released in a Camel 1.5, while trunk is moving towards 2.0?

On the documentation side of things, we already had a few 
questions/remarks on improving the documentation about the DSLs 
themselves.  Any suggestions on how we can do this?  There has also been 
talk on revamping the look and feel of the website somewhat, to make it 
easier for users to get started with Camel.  Any ideas on this?




View raw message