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 bel
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
wrote:
I have another proposal that could work better and is quite near
On Thu, Aug 25, 2011 at 10:17 AM, Claus Ibsen wrote:
> On Thu, Aug 25, 2011 at 9:40 AM, Christian Schneider
> wrote:
>> I have another proposal that could work better and is quite near to what we
>> have.
>>
>> org.apache.camel.management.api
We could consider placing the new ManagedXXX annotati
On Wed, Aug 24, 2011 at 7:55 PM, Christian Schneider
wrote:
> Actually JDk and spring are two very good examples how to not do it :-)
>
Yeah I guess using them as an example was "too easy" and it was late
last evening.
But often people would refer and look at giants such as the JDK and Spring.
I
On Thu, Aug 25, 2011 at 9:40 AM, Christian Schneider
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 p
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
eventually we could have
org.apache.camel.management.api.annotations
So the idea in this case is to have the modu
Actually I think it would be better to put annotations in their own package:
org.apache.camel.annotation
org.apache.camel.annotation.management
org.apache.camel.annotation.etc...
Then it won't feel weird that
org.apache.camel.management is not there
My $0.02,
Hadrian
On 08/24/2011 01:55 PM, C
Actually JDk and spring are two very good examples how to not do it :-)
I guess in the JDK no one cared as you will always have it. Btw. I guess
everyone agrees that the JDK is a mess architecturally. Btw. he JDK
extensions ship separate API jars like JAXB api. So they seem to have
learned.
On Wed, Aug 24, 2011 at 6:17 PM, Christian Schneider
wrote:
> Hi Claus,
>
> we can do that but then we have to move the impl classes somewhere else. We
> may not mix impl and api in the same package. This is what leads to cycles.
>
That is actually common. For example look at the JDK
Map (API) an
Hi Claus,
we can do that but then we have to move the impl classes somewhere else.
We may not mix impl and api in the same package. This is what leads to
cycles.
Christian
Am 24.08.2011 17:53, schrieb Claus Ibsen:
On Wed, Aug 24, 2011 at 3:04 PM, Christian Schneider
wrote:
So where do y
On Wed, Aug 24, 2011 at 3:04 PM, Christian Schneider
wrote:
> So where do you propose to put them?
>
> 1. org.apache.camel
> 2. org.apache.camel.api.management
>
I propose to put them here, where they where already
3. org.apache.camel.management
These annotations are part of the management API i
So where do you propose to put them?
1. org.apache.camel
2. org.apache.camel.api.management
I propose to go with 2 and create an api package with subpackages so we
can structure org.apache.camel better. In the long run I would like to
also move the whole camel api into an api package to make i
On Tue, Aug 23, 2011 at 12:38 PM, Christian Schneider
wrote:
> I wonder what our scope for the org.apache.camel.spi package is vs the
> org.apache.camel (API) package.
>
> I know two valid definitions for API vs SPI:
>
> 1) API interfaces are called by the user to invoke functionality of the
> fra
13 matches
Mail list logo
