Hi Willem,
as long as camel keeps compatible with most user code out there I see no
big problems in having the refactoring earlier.
Currently I already moved the management API to spi.management. As we
discussed it is not so well placed there. So I propose to do the change
like described below.
Regarding compatibility:
- The annotations are new in 2.9 so they will not affect users
- The rest of the interfaces seems to be mainly used internally so I
expect at least almost no problems
- The impl classes should not be used by users anyways so I expect no
problems there
Christian
Am 25.08.2011 11:24, schrieb Willem Jiang:
Maybe we can consider to move to Camel 3.0 after Camel 2.9.0 is
released, and leave this kind of package refactor to Camel 3.0.
On 8/25/11 4:17 PM, Claus Ibsen wrote:
On Thu, Aug 25, 2011 at 9:40 AM, Christian Schneider
<ch...@die-schneider.net> wrote:
I have another proposal that could work better and is quite near to
what we
have.
org.apache.camel.management.api
org.apache.camel.management.event
org.apache.camel.management.impl
This kind of split into fine grained sub packages is a neat idea.
However I suggest to keep this for Camel 3.0 where the camel-core can
be possible be split into smaller JARs and separate API vs default
impl.
As I have said many times. Camel 2.x is 2+ years old, and we are in
the 9th release, and we have a large end user base who depend upon the
API is
kept stable as is.
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
