Hi
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 from(xxx).to("log:hello")
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
......................................
Silverbullet
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576
Web: www.silverbullet.dk
-----Original Message-----
From: Gert Vanthienen [mailto:[EMAIL PROTECTED]
Sent: 22. juli 2008 14:44
To: [email protected]
Subject: Roadmap after Camel 1.4 release
L.S.,
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
suggestions?
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?
Regards,
Gert
[1]
https://issues.apache.org/activemq/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=11020&fixfor=11922
[2]
https://issues.apache.org/activemq/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=11020&fixfor=11900
