Donald, you are mostly correct, this would require mostly repackaging of
the jars, i.e. splitting the core into multiple jars. We will probably
have to do something with the CamelContext, it became a bit of a
hodge-podge. In any case, the intent is for the migration to be still
simple and straightforward. The mantra of Camel is to make integration
*simple*.
Most of the API is great but it gained a lot of extra fat not really
used by users. There are a few other issues. I don't want to say more
about this now, simply because my crystal ball is blurry and it'll take
quite a few discussions on dev@ to sort this out. So stay tuned and
remember that your feedback is appreciated, pitch in and don't be shy
(well, Donald, you sent this one, looks like you're not :), so guys,
follow Donald's example). Your success and mental health is important to
us, we'll try to not go overboard.
Cheers,
Hadrian
On 09/24/2011 09:31 PM, Donald Whytock wrote:
On Sat, Sep 24, 2011 at 9:14 PM, Hadrian Zbarcea<hzbar...@gmail.com> wrote:
* cleanup the api an architecture to allow one to use camel as an
integration framework *without* the routing part. For instance one should be
able to use just a producer template and the components of choice with a
lean runtime (without the dsl, some processors maybe, support for routing,
etc)
+1 on this one...let Camel be a protocol repository. Possibly also
allowing an endpoint to act as a simple readable BlockingQueue.
Though this wouldn't necessarily be a compatibility problem, would it?
Could it not be done as a new layer under the routing, leaving the
existing API intact?
Don
