You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Christian Schneider <ch...@die-schneider.net> on 2011/08/23 12:38:11 UTC

Scope of org.apache.camel.spi

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 
framework. So API interfaces are implemented by the framework. SPI 
interfaces are implemented by the user to change functionality of the 
framework or for callbacks
2) SPI interfaces are for third party modules while API interfaces are 
for users

So the current case for me is the new JMX annotations. Are they SPI 
interfaces or API interfaces?

So what is your opinion about the specific and the general case.

As a side question: The org.apache.camel package has grown quite large. 
I think we should create specialized packages for it. As we are talking 
about the camel API org.apache.camel.api.* would be a good name in my 
opinion. So the questions are: Should we create such specialized 
packages? Should we move API parts there? Should we only use the new 
packages for new stuff?

Christian


-- 
--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: Scope of org.apache.camel.spi

Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Aug 24, 2011 at 7:55 PM, Christian Schneider
<ch...@die-schneider.net> 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.
If you talk with the spring core team they always praise themselves as
great API builders.
And yeah they have succeeded IMHO to have a long line of releases with
a stable API and making it very/fairly easy for end user to upgrade.
For example many Spring 2.x apps would run fine in 3.x. Even older
releases as well.

But that said, the illusion with Spring is that its "all or nothing".
So if you depend on one piece of Spring, you usually end up taking in
X+ JARs.
Just as the JMX example with Camel. I guess the Spring Expression
Language would be another such example.

And Spring is not as friendly for other framework builders, so there
is not so many hooks we can leverage to influence spring.
For example their property placeholder mechanism is a prime example.



> 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.

Yeah Oracle is looking into project jigsaw to try to refactor the JDK.
That said the JDK has a remarkable backwards compatibility.
Even so extreme that people have suggested to create a new Java, and
dump the old cruft / @deprecated stuff etc.

But that is another story that isn't very relevant in this thread.

And of course Apache Camel should not be this extreme.
Yes we have changed the API a bit between minor releases. Especially
in the earlier releases of Camel 2.x where the API need to "settle
down".
But now in 9th release and going for 10th (Camel 2.9), the API ought
to be stable.

The changes you have done so far on trunk is IMHO good and fine.
eg ServiceSupport into the support package. And have the old API
marked as @deprecated.
Even its not an absolute 100% backwards compatible change, as the impl
is now using ServiceSupport from support package and not the old
@deprecated one.
So end users who oddly would type cast to ServiceSupport would have a
type cast exception now. In fact one unit test in camel-ftp did that.
But that is very uncommon for end users to do so I think the change is fine.



>
> In spring I suspect it is on purpose. They could provide API jars that make
> you independent of their implementation. By combining API and impl they
> force you into having a hard dependency on spring.
> You had to remove the spring JMX annotations as we did not want to have
> their impl. If they had cleanly separated their API from the impl we could
> have kept the one API jar with the annotations and just implemented them
> ourself when running outside of spring.
>
> So having the annotations in the management package is a very bad idea. A
> subpackage would work on a pure simple package perspective but I think it
> would be bad to have a top level package with implementations and a
> subpackage with the API.
>
> We can move around the management stuff at the moment as my commit changed
> it anyway. So before Camel 2.9 comes out we are free to move them.
>
> api.management of course only makes sense if we intend to put more stuff
> there but I think it would be a good idea to do so.
> Having a top level api package will also make it easier to create a pure API
> jar for camel 3.0. I think it would be strange if the API jar would contain
>
> org.apache.camel
> org.apache.camel.spi
> org.apache.camel.management.annotation
>
> but not
> org.apache.camel.management
>
> Btw management.annotation is not enough anyway as we have more management
> interfaces that have to live in the API space. So management.api would be
> better but I would prefer to have api at the top level so the user can
> clearly see that everything api.* is part of the API.
>
> In any case we need to separate the management API from the management impl
> classes. If we do not do it then we have no chance to avoid cycles. Besides
> that how should we make it possible that the components only need to depend
> on the API if we mix things. For example a component may want to use the
> management annotations or another management interface but it should not
> know the impl.
>
> Btw. the event classes should also be part of the API as they are necessary
> to understand management events. As they live in a separate package already
> the does not depend on the management impl I did not move them but they
> would be better placed in api.management.events.
>
> Christian
>
>
>
>
> Am 24.08.2011 19:12, schrieb Claus Ibsen:
>>
>> On Wed, Aug 24, 2011 at 6:17 PM, Christian Schneider
>> <ch...@die-schneider.net>  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) and HashMap (Impl) are both in java.util package.
>>
>> However these annotations are not regular interfaces, that end users
>> is supposed to implement.
>> Or for example that we in the Apache Camel provides 2+ different
>> implements of those annotations.
>>
>> As an end user I would feel natural these annotations are in the
>> mangement package as they are part of the management
>> (end user) API in Camel.
>>
>>
>> The Spring framework put these annotations at
>>
>> http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/jmx/export/annotation/ManagedOperation.html
>>
>> We could also have a annotation subpackage
>> (org.apache.camel.management.annotation)
>> but we usually dont have that, eg there are no annotation package for
>> @Consume, @Produce, @EndpointInject etc.
>>
>> Alternatively we could move them in the root package, but as you said
>> there is already plenty of APIs in that package.
>>
>> Putting them in org.apache.camel.api seems a bit weird, as they would
>> be the only pieces in there.
>> And for Camel 2.x we should keep the API stable and not move around
>> stuff all the time.
>>
>>
>>
>>> Christian
>>>
>>>
>>> Am 24.08.2011 17:53, schrieb Claus Ibsen:
>>>>
>>>> On Wed, Aug 24, 2011 at 3:04 PM, Christian Schneider
>>>> <ch...@die-schneider.net>    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 in Camel and IMHO
>>>> should be in that package.
>>>>
>>>>
>>>>
>>>>> 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 it clearer but that
>>>>> will
>>>>> probably create too much incompatibility.
>>>>>
>>>>> Christian
>>>>>
>>>>>
>>>>> Am 24.08.2011 14:13, schrieb Claus Ibsen:
>>>>>>
>>>>>> On Tue, Aug 23, 2011 at 12:38 PM, Christian Schneider
>>>>>> <ch...@die-schneider.net>      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
>>>>>>> framework. So API interfaces are implemented by the framework. SPI
>>>>>>> interfaces are implemented by the user to change functionality of the
>>>>>>> framework or for callbacks
>>>>>>> 2) SPI interfaces are for third party modules while API interfaces
>>>>>>> are
>>>>>>> for
>>>>>>> users
>>>>>>>
>>>>>>> So the current case for me is the new JMX annotations. Are they SPI
>>>>>>> interfaces or API interfaces?
>>>>>>>
>>>>>> They are API interfaces. Just like @Consumer, @Produce and any of the
>>>>>> other API Camel annotations we have.
>>>>>> Its just that these annotations is for management enabling your
>>>>>> business logic / custom components or whatnot.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> So what is your opinion about the specific and the general case.
>>>>>>>
>>>>>>> As a side question: The org.apache.camel package has grown quite
>>>>>>> large.
>>>>>>> I
>>>>>>> think we should create specialized packages for it. As we are talking
>>>>>>> about
>>>>>>> the camel API org.apache.camel.api.* would be a good name in my
>>>>>>> opinion.
>>>>>>> So
>>>>>>> the questions are: Should we create such specialized packages? Should
>>>>>>> we
>>>>>>> move API parts there? Should we only use the new packages for new
>>>>>>> stuff?
>>>>>>>
>>>>>>> Christian
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> --
>>>>>>> Christian Schneider
>>>>>>> http://www.liquid-reality.de
>>>>>>>
>>>>>>> Open Source Architect
>>>>>>> Talend Application Integration Division http://www.talend.com
>>>>>>>
>>>>>>>
>>>>> --
>>>>> --
>>>>> Christian Schneider
>>>>> http://www.liquid-reality.de
>>>>>
>>>>> Open Source Architect
>>>>> Talend Application Integration Division http://www.talend.com
>>>>>
>>>>>
>>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
>>>
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Scope of org.apache.camel.spi

Posted by Christian Schneider <ch...@die-schneider.net>.
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

Re: Scope of org.apache.camel.spi

Posted by Willem Jiang <wi...@gmail.com>.
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.
>
>
>
>> eventually we could have
>> org.apache.camel.management.api.annotations
>>
>
> I actually dont like the .annotation package. For me an annotation is
> just like any other API, whether its an interface, enum, exception,
> etc.
>
>
>> So the idea in this case is to have the module management on top level.
>> Basically I like this even more than a technical split (api, impl) at the
>> top level.
>>
>> The main change would be to leave the org.apache.management package empty.
>> So a split of api+event in one jar and impl in another would be easier.
>> This would also match very well with how osgi jars work.  Where you can have
>> the whole management in one jar and only publish the api+event packages.
>>
>
> Yeah that seems like a good plane for Camel 3.0.
>
> And talking about Camel 3.0, we may start a [DISCUSS] thread to start
> talking about when we should go about doing it.
> In terms of your work on the API in the camel-core, we may push
> forward and get sooner started on Camel 3.0.
>
>
>
>> Christian
>>
>> Am 24.08.2011 23:45, schrieb Hadrian Zbarcea:
>>>
>>> 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, Christian Schneider wrote:
>>>>
>>>> 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.
>>>>
>>>> In spring I suspect it is on purpose. They could provide API jars that
>>>> make you independent of their implementation. By combining API and impl
>>>> they force you into having a hard dependency on spring.
>>>> You had to remove the spring JMX annotations as we did not want to have
>>>> their impl. If they had cleanly separated their API from the impl we
>>>> could have kept the one API jar with the annotations and just
>>>> implemented them ourself when running outside of spring.
>>>>
>>>> So having the annotations in the management package is a very bad idea.
>>>> A subpackage would work on a pure simple package perspective but I think
>>>> it would be bad to have a top level package with implementations and a
>>>> subpackage with the API.
>>>>
>>>> We can move around the management stuff at the moment as my commit
>>>> changed it anyway. So before Camel 2.9 comes out we are free to move
>>>> them.
>>>>
>>>> api.management of course only makes sense if we intend to put more stuff
>>>> there but I think it would be a good idea to do so.
>>>> Having a top level api package will also make it easier to create a pure
>>>> API jar for camel 3.0. I think it would be strange if the API jar would
>>>> contain
>>>>
>>>> org.apache.camel
>>>> org.apache.camel.spi
>>>> org.apache.camel.management.annotation
>>>>
>>>> but not
>>>> org.apache.camel.management
>>>>
>>>> Btw management.annotation is not enough anyway as we have more
>>>> management interfaces that have to live in the API space. So
>>>> management.api would be better but I would prefer to have api at the top
>>>> level so the user can clearly see that everything api.* is part of the
>>>> API.
>>>>
>>>> In any case we need to separate the management API from the management
>>>> impl classes. If we do not do it then we have no chance to avoid cycles.
>>>> Besides that how should we make it possible that the components only
>>>> need to depend on the API if we mix things. For example a component may
>>>> want to use the management annotations or another management interface
>>>> but it should not know the impl.
>>>>
>>>> Btw. the event classes should also be part of the API as they are
>>>> necessary to understand management events. As they live in a separate
>>>> package already the does not depend on the management impl I did not
>>>> move them but they would be better placed in api.management.events.
>>>>
>>>> Christian
>>>>
>>>>
>>>>
>>>>
>>>> Am 24.08.2011 19:12, schrieb Claus Ibsen:
>>>>>
>>>>> On Wed, Aug 24, 2011 at 6:17 PM, Christian Schneider
>>>>> <ch...@die-schneider.net>  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) and HashMap (Impl) are both in java.util package.
>>>>>
>>>>> However these annotations are not regular interfaces, that end users
>>>>> is supposed to implement.
>>>>> Or for example that we in the Apache Camel provides 2+ different
>>>>> implements of those annotations.
>>>>>
>>>>> As an end user I would feel natural these annotations are in the
>>>>> mangement package as they are part of the management
>>>>> (end user) API in Camel.
>>>>>
>>>>>
>>>>> The Spring framework put these annotations at
>>>>>
>>>>> http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/jmx/export/annotation/ManagedOperation.html
>>>>>
>>>>>
>>>>> We could also have a annotation subpackage
>>>>> (org.apache.camel.management.annotation)
>>>>> but we usually dont have that, eg there are no annotation package for
>>>>> @Consume, @Produce, @EndpointInject etc.
>>>>>
>>>>> Alternatively we could move them in the root package, but as you said
>>>>> there is already plenty of APIs in that package.
>>>>>
>>>>> Putting them in org.apache.camel.api seems a bit weird, as they would
>>>>> be the only pieces in there.
>>>>> And for Camel 2.x we should keep the API stable and not move around
>>>>> stuff all the time.
>>>>>
>>>>>
>>>>>
>>>>>> Christian
>>>>>>
>>>>>>
>>>>>> Am 24.08.2011 17:53, schrieb Claus Ibsen:
>>>>>>>
>>>>>>> On Wed, Aug 24, 2011 at 3:04 PM, Christian Schneider
>>>>>>> <ch...@die-schneider.net>  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 in Camel and IMHO
>>>>>>> should be in that package.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> 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 it clearer but that
>>>>>>>> will
>>>>>>>> probably create too much incompatibility.
>>>>>>>>
>>>>>>>> Christian
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 24.08.2011 14:13, schrieb Claus Ibsen:
>>>>>>>>>
>>>>>>>>> On Tue, Aug 23, 2011 at 12:38 PM, Christian Schneider
>>>>>>>>> <ch...@die-schneider.net>  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
>>>>>>>>>> framework. So API interfaces are implemented by the framework. SPI
>>>>>>>>>> interfaces are implemented by the user to change functionality of
>>>>>>>>>> the
>>>>>>>>>> framework or for callbacks
>>>>>>>>>> 2) SPI interfaces are for third party modules while API
>>>>>>>>>> interfaces are
>>>>>>>>>> for
>>>>>>>>>> users
>>>>>>>>>>
>>>>>>>>>> So the current case for me is the new JMX annotations. Are they SPI
>>>>>>>>>> interfaces or API interfaces?
>>>>>>>>>>
>>>>>>>>> They are API interfaces. Just like @Consumer, @Produce and any of
>>>>>>>>> the
>>>>>>>>> other API Camel annotations we have.
>>>>>>>>> Its just that these annotations is for management enabling your
>>>>>>>>> business logic / custom components or whatnot.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> So what is your opinion about the specific and the general case.
>>>>>>>>>>
>>>>>>>>>> As a side question: The org.apache.camel package has grown quite
>>>>>>>>>> large.
>>>>>>>>>> I
>>>>>>>>>> think we should create specialized packages for it. As we are
>>>>>>>>>> talking
>>>>>>>>>> about
>>>>>>>>>> the camel API org.apache.camel.api.* would be a good name in my
>>>>>>>>>> opinion.
>>>>>>>>>> So
>>>>>>>>>> the questions are: Should we create such specialized packages?
>>>>>>>>>> Should
>>>>>>>>>> we
>>>>>>>>>> move API parts there? Should we only use the new packages for new
>>>>>>>>>> stuff?
>>>>>>>>>>
>>>>>>>>>> Christian
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> --
>>>>>>>>>> Christian Schneider
>>>>>>>>>> http://www.liquid-reality.de
>>>>>>>>>>
>>>>>>>>>> Open Source Architect
>>>>>>>>>> Talend Application Integration Division http://www.talend.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> --
>>>>>>>> --
>>>>>>>> Christian Schneider
>>>>>>>> http://www.liquid-reality.de
>>>>>>>>
>>>>>>>> Open Source Architect
>>>>>>>> Talend Application Integration Division http://www.talend.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Christian Schneider
>>>>>> http://www.liquid-reality.de
>>>>>>
>>>>>> Open Source Architect
>>>>>> http://www.talend.com
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> --
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>>
>
>
>


-- 
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog:    http://willemjiang.blogspot.com (English)
          http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang

Re: Scope of org.apache.camel.spi

Posted by Claus Ibsen <cl...@gmail.com>.
On Thu, Aug 25, 2011 at 10:17 AM, Claus Ibsen <cl...@gmail.com> 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

We could consider placing the new ManagedXXX annotations in this
package in light of that this is the package structure we want
to go with in the future, eg Camel 3.0.

And then lave the current API as is, so there is no trouble for out
existing user base.


>> 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.
>
>
>
>> eventually we could have
>> org.apache.camel.management.api.annotations
>>
>
> I actually dont like the .annotation package. For me an annotation is
> just like any other API, whether its an interface, enum, exception,
> etc.
>
>
>> So the idea in this case is to have the module management on top level.
>> Basically I like this even more than a technical split (api, impl) at the
>> top level.
>>
>> The main change would be to leave the org.apache.management package empty.
>> So a split of api+event in one jar and impl in another would be easier.
>> This would also match very well with how osgi jars work.  Where you can have
>> the whole management in one jar and only publish the api+event packages.
>>
>
> Yeah that seems like a good plane for Camel 3.0.
>
> And talking about Camel 3.0, we may start a [DISCUSS] thread to start
> talking about when we should go about doing it.
> In terms of your work on the API in the camel-core, we may push
> forward and get sooner started on Camel 3.0.
>
>
>
>> Christian
>>
>> Am 24.08.2011 23:45, schrieb Hadrian Zbarcea:
>>>
>>> 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, Christian Schneider wrote:
>>>>
>>>> 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.
>>>>
>>>> In spring I suspect it is on purpose. They could provide API jars that
>>>> make you independent of their implementation. By combining API and impl
>>>> they force you into having a hard dependency on spring.
>>>> You had to remove the spring JMX annotations as we did not want to have
>>>> their impl. If they had cleanly separated their API from the impl we
>>>> could have kept the one API jar with the annotations and just
>>>> implemented them ourself when running outside of spring.
>>>>
>>>> So having the annotations in the management package is a very bad idea.
>>>> A subpackage would work on a pure simple package perspective but I think
>>>> it would be bad to have a top level package with implementations and a
>>>> subpackage with the API.
>>>>
>>>> We can move around the management stuff at the moment as my commit
>>>> changed it anyway. So before Camel 2.9 comes out we are free to move
>>>> them.
>>>>
>>>> api.management of course only makes sense if we intend to put more stuff
>>>> there but I think it would be a good idea to do so.
>>>> Having a top level api package will also make it easier to create a pure
>>>> API jar for camel 3.0. I think it would be strange if the API jar would
>>>> contain
>>>>
>>>> org.apache.camel
>>>> org.apache.camel.spi
>>>> org.apache.camel.management.annotation
>>>>
>>>> but not
>>>> org.apache.camel.management
>>>>
>>>> Btw management.annotation is not enough anyway as we have more
>>>> management interfaces that have to live in the API space. So
>>>> management.api would be better but I would prefer to have api at the top
>>>> level so the user can clearly see that everything api.* is part of the
>>>> API.
>>>>
>>>> In any case we need to separate the management API from the management
>>>> impl classes. If we do not do it then we have no chance to avoid cycles.
>>>> Besides that how should we make it possible that the components only
>>>> need to depend on the API if we mix things. For example a component may
>>>> want to use the management annotations or another management interface
>>>> but it should not know the impl.
>>>>
>>>> Btw. the event classes should also be part of the API as they are
>>>> necessary to understand management events. As they live in a separate
>>>> package already the does not depend on the management impl I did not
>>>> move them but they would be better placed in api.management.events.
>>>>
>>>> Christian
>>>>
>>>>
>>>>
>>>>
>>>> Am 24.08.2011 19:12, schrieb Claus Ibsen:
>>>>>
>>>>> On Wed, Aug 24, 2011 at 6:17 PM, Christian Schneider
>>>>> <ch...@die-schneider.net> 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) and HashMap (Impl) are both in java.util package.
>>>>>
>>>>> However these annotations are not regular interfaces, that end users
>>>>> is supposed to implement.
>>>>> Or for example that we in the Apache Camel provides 2+ different
>>>>> implements of those annotations.
>>>>>
>>>>> As an end user I would feel natural these annotations are in the
>>>>> mangement package as they are part of the management
>>>>> (end user) API in Camel.
>>>>>
>>>>>
>>>>> The Spring framework put these annotations at
>>>>>
>>>>> http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/jmx/export/annotation/ManagedOperation.html
>>>>>
>>>>>
>>>>> We could also have a annotation subpackage
>>>>> (org.apache.camel.management.annotation)
>>>>> but we usually dont have that, eg there are no annotation package for
>>>>> @Consume, @Produce, @EndpointInject etc.
>>>>>
>>>>> Alternatively we could move them in the root package, but as you said
>>>>> there is already plenty of APIs in that package.
>>>>>
>>>>> Putting them in org.apache.camel.api seems a bit weird, as they would
>>>>> be the only pieces in there.
>>>>> And for Camel 2.x we should keep the API stable and not move around
>>>>> stuff all the time.
>>>>>
>>>>>
>>>>>
>>>>>> Christian
>>>>>>
>>>>>>
>>>>>> Am 24.08.2011 17:53, schrieb Claus Ibsen:
>>>>>>>
>>>>>>> On Wed, Aug 24, 2011 at 3:04 PM, Christian Schneider
>>>>>>> <ch...@die-schneider.net> 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 in Camel and IMHO
>>>>>>> should be in that package.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> 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 it clearer but that
>>>>>>>> will
>>>>>>>> probably create too much incompatibility.
>>>>>>>>
>>>>>>>> Christian
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 24.08.2011 14:13, schrieb Claus Ibsen:
>>>>>>>>>
>>>>>>>>> On Tue, Aug 23, 2011 at 12:38 PM, Christian Schneider
>>>>>>>>> <ch...@die-schneider.net> 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
>>>>>>>>>> framework. So API interfaces are implemented by the framework. SPI
>>>>>>>>>> interfaces are implemented by the user to change functionality of
>>>>>>>>>> the
>>>>>>>>>> framework or for callbacks
>>>>>>>>>> 2) SPI interfaces are for third party modules while API
>>>>>>>>>> interfaces are
>>>>>>>>>> for
>>>>>>>>>> users
>>>>>>>>>>
>>>>>>>>>> So the current case for me is the new JMX annotations. Are they SPI
>>>>>>>>>> interfaces or API interfaces?
>>>>>>>>>>
>>>>>>>>> They are API interfaces. Just like @Consumer, @Produce and any of
>>>>>>>>> the
>>>>>>>>> other API Camel annotations we have.
>>>>>>>>> Its just that these annotations is for management enabling your
>>>>>>>>> business logic / custom components or whatnot.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> So what is your opinion about the specific and the general case.
>>>>>>>>>>
>>>>>>>>>> As a side question: The org.apache.camel package has grown quite
>>>>>>>>>> large.
>>>>>>>>>> I
>>>>>>>>>> think we should create specialized packages for it. As we are
>>>>>>>>>> talking
>>>>>>>>>> about
>>>>>>>>>> the camel API org.apache.camel.api.* would be a good name in my
>>>>>>>>>> opinion.
>>>>>>>>>> So
>>>>>>>>>> the questions are: Should we create such specialized packages?
>>>>>>>>>> Should
>>>>>>>>>> we
>>>>>>>>>> move API parts there? Should we only use the new packages for new
>>>>>>>>>> stuff?
>>>>>>>>>>
>>>>>>>>>> Christian
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> --
>>>>>>>>>> Christian Schneider
>>>>>>>>>> http://www.liquid-reality.de
>>>>>>>>>>
>>>>>>>>>> Open Source Architect
>>>>>>>>>> Talend Application Integration Division http://www.talend.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> --
>>>>>>>> --
>>>>>>>> Christian Schneider
>>>>>>>> http://www.liquid-reality.de
>>>>>>>>
>>>>>>>> Open Source Architect
>>>>>>>> Talend Application Integration Division http://www.talend.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Christian Schneider
>>>>>> http://www.liquid-reality.de
>>>>>>
>>>>>> Open Source Architect
>>>>>> http://www.talend.com
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> --
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>>
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Scope of org.apache.camel.spi

Posted by Claus Ibsen <cl...@gmail.com>.
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.



> eventually we could have
> org.apache.camel.management.api.annotations
>

I actually dont like the .annotation package. For me an annotation is
just like any other API, whether its an interface, enum, exception,
etc.


> So the idea in this case is to have the module management on top level.
> Basically I like this even more than a technical split (api, impl) at the
> top level.
>
> The main change would be to leave the org.apache.management package empty.
> So a split of api+event in one jar and impl in another would be easier.
> This would also match very well with how osgi jars work.  Where you can have
> the whole management in one jar and only publish the api+event packages.
>

Yeah that seems like a good plane for Camel 3.0.

And talking about Camel 3.0, we may start a [DISCUSS] thread to start
talking about when we should go about doing it.
In terms of your work on the API in the camel-core, we may push
forward and get sooner started on Camel 3.0.



> Christian
>
> Am 24.08.2011 23:45, schrieb Hadrian Zbarcea:
>>
>> 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, Christian Schneider wrote:
>>>
>>> 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.
>>>
>>> In spring I suspect it is on purpose. They could provide API jars that
>>> make you independent of their implementation. By combining API and impl
>>> they force you into having a hard dependency on spring.
>>> You had to remove the spring JMX annotations as we did not want to have
>>> their impl. If they had cleanly separated their API from the impl we
>>> could have kept the one API jar with the annotations and just
>>> implemented them ourself when running outside of spring.
>>>
>>> So having the annotations in the management package is a very bad idea.
>>> A subpackage would work on a pure simple package perspective but I think
>>> it would be bad to have a top level package with implementations and a
>>> subpackage with the API.
>>>
>>> We can move around the management stuff at the moment as my commit
>>> changed it anyway. So before Camel 2.9 comes out we are free to move
>>> them.
>>>
>>> api.management of course only makes sense if we intend to put more stuff
>>> there but I think it would be a good idea to do so.
>>> Having a top level api package will also make it easier to create a pure
>>> API jar for camel 3.0. I think it would be strange if the API jar would
>>> contain
>>>
>>> org.apache.camel
>>> org.apache.camel.spi
>>> org.apache.camel.management.annotation
>>>
>>> but not
>>> org.apache.camel.management
>>>
>>> Btw management.annotation is not enough anyway as we have more
>>> management interfaces that have to live in the API space. So
>>> management.api would be better but I would prefer to have api at the top
>>> level so the user can clearly see that everything api.* is part of the
>>> API.
>>>
>>> In any case we need to separate the management API from the management
>>> impl classes. If we do not do it then we have no chance to avoid cycles.
>>> Besides that how should we make it possible that the components only
>>> need to depend on the API if we mix things. For example a component may
>>> want to use the management annotations or another management interface
>>> but it should not know the impl.
>>>
>>> Btw. the event classes should also be part of the API as they are
>>> necessary to understand management events. As they live in a separate
>>> package already the does not depend on the management impl I did not
>>> move them but they would be better placed in api.management.events.
>>>
>>> Christian
>>>
>>>
>>>
>>>
>>> Am 24.08.2011 19:12, schrieb Claus Ibsen:
>>>>
>>>> On Wed, Aug 24, 2011 at 6:17 PM, Christian Schneider
>>>> <ch...@die-schneider.net> 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) and HashMap (Impl) are both in java.util package.
>>>>
>>>> However these annotations are not regular interfaces, that end users
>>>> is supposed to implement.
>>>> Or for example that we in the Apache Camel provides 2+ different
>>>> implements of those annotations.
>>>>
>>>> As an end user I would feel natural these annotations are in the
>>>> mangement package as they are part of the management
>>>> (end user) API in Camel.
>>>>
>>>>
>>>> The Spring framework put these annotations at
>>>>
>>>> http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/jmx/export/annotation/ManagedOperation.html
>>>>
>>>>
>>>> We could also have a annotation subpackage
>>>> (org.apache.camel.management.annotation)
>>>> but we usually dont have that, eg there are no annotation package for
>>>> @Consume, @Produce, @EndpointInject etc.
>>>>
>>>> Alternatively we could move them in the root package, but as you said
>>>> there is already plenty of APIs in that package.
>>>>
>>>> Putting them in org.apache.camel.api seems a bit weird, as they would
>>>> be the only pieces in there.
>>>> And for Camel 2.x we should keep the API stable and not move around
>>>> stuff all the time.
>>>>
>>>>
>>>>
>>>>> Christian
>>>>>
>>>>>
>>>>> Am 24.08.2011 17:53, schrieb Claus Ibsen:
>>>>>>
>>>>>> On Wed, Aug 24, 2011 at 3:04 PM, Christian Schneider
>>>>>> <ch...@die-schneider.net> 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 in Camel and IMHO
>>>>>> should be in that package.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 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 it clearer but that
>>>>>>> will
>>>>>>> probably create too much incompatibility.
>>>>>>>
>>>>>>> Christian
>>>>>>>
>>>>>>>
>>>>>>> Am 24.08.2011 14:13, schrieb Claus Ibsen:
>>>>>>>>
>>>>>>>> On Tue, Aug 23, 2011 at 12:38 PM, Christian Schneider
>>>>>>>> <ch...@die-schneider.net> 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
>>>>>>>>> framework. So API interfaces are implemented by the framework. SPI
>>>>>>>>> interfaces are implemented by the user to change functionality of
>>>>>>>>> the
>>>>>>>>> framework or for callbacks
>>>>>>>>> 2) SPI interfaces are for third party modules while API
>>>>>>>>> interfaces are
>>>>>>>>> for
>>>>>>>>> users
>>>>>>>>>
>>>>>>>>> So the current case for me is the new JMX annotations. Are they SPI
>>>>>>>>> interfaces or API interfaces?
>>>>>>>>>
>>>>>>>> They are API interfaces. Just like @Consumer, @Produce and any of
>>>>>>>> the
>>>>>>>> other API Camel annotations we have.
>>>>>>>> Its just that these annotations is for management enabling your
>>>>>>>> business logic / custom components or whatnot.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> So what is your opinion about the specific and the general case.
>>>>>>>>>
>>>>>>>>> As a side question: The org.apache.camel package has grown quite
>>>>>>>>> large.
>>>>>>>>> I
>>>>>>>>> think we should create specialized packages for it. As we are
>>>>>>>>> talking
>>>>>>>>> about
>>>>>>>>> the camel API org.apache.camel.api.* would be a good name in my
>>>>>>>>> opinion.
>>>>>>>>> So
>>>>>>>>> the questions are: Should we create such specialized packages?
>>>>>>>>> Should
>>>>>>>>> we
>>>>>>>>> move API parts there? Should we only use the new packages for new
>>>>>>>>> stuff?
>>>>>>>>>
>>>>>>>>> Christian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> --
>>>>>>>>> Christian Schneider
>>>>>>>>> http://www.liquid-reality.de
>>>>>>>>>
>>>>>>>>> Open Source Architect
>>>>>>>>> Talend Application Integration Division http://www.talend.com
>>>>>>>>>
>>>>>>>>>
>>>>>>> --
>>>>>>> --
>>>>>>> Christian Schneider
>>>>>>> http://www.liquid-reality.de
>>>>>>>
>>>>>>> Open Source Architect
>>>>>>> Talend Application Integration Division http://www.talend.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>> --
>>>>> Christian Schneider
>>>>> http://www.liquid-reality.de
>>>>>
>>>>> Open Source Architect
>>>>> http://www.talend.com
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Scope of org.apache.camel.spi

Posted by Christian Schneider <ch...@die-schneider.net>.
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 module management on top level. 
Basically I like this even more than a technical split (api, impl) at 
the top level.

The main change would be to leave the org.apache.management package 
empty. So a split of api+event in one jar and impl in another would be 
easier.
This would also match very well with how osgi jars work.  Where you can 
have the whole management in one jar and only publish the api+event 
packages.

Christian

Am 24.08.2011 23:45, schrieb Hadrian Zbarcea:
> 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, Christian Schneider wrote:
>> 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.
>>
>> In spring I suspect it is on purpose. They could provide API jars that
>> make you independent of their implementation. By combining API and impl
>> they force you into having a hard dependency on spring.
>> You had to remove the spring JMX annotations as we did not want to have
>> their impl. If they had cleanly separated their API from the impl we
>> could have kept the one API jar with the annotations and just
>> implemented them ourself when running outside of spring.
>>
>> So having the annotations in the management package is a very bad idea.
>> A subpackage would work on a pure simple package perspective but I think
>> it would be bad to have a top level package with implementations and a
>> subpackage with the API.
>>
>> We can move around the management stuff at the moment as my commit
>> changed it anyway. So before Camel 2.9 comes out we are free to move 
>> them.
>>
>> api.management of course only makes sense if we intend to put more stuff
>> there but I think it would be a good idea to do so.
>> Having a top level api package will also make it easier to create a pure
>> API jar for camel 3.0. I think it would be strange if the API jar would
>> contain
>>
>> org.apache.camel
>> org.apache.camel.spi
>> org.apache.camel.management.annotation
>>
>> but not
>> org.apache.camel.management
>>
>> Btw management.annotation is not enough anyway as we have more
>> management interfaces that have to live in the API space. So
>> management.api would be better but I would prefer to have api at the top
>> level so the user can clearly see that everything api.* is part of 
>> the API.
>>
>> In any case we need to separate the management API from the management
>> impl classes. If we do not do it then we have no chance to avoid cycles.
>> Besides that how should we make it possible that the components only
>> need to depend on the API if we mix things. For example a component may
>> want to use the management annotations or another management interface
>> but it should not know the impl.
>>
>> Btw. the event classes should also be part of the API as they are
>> necessary to understand management events. As they live in a separate
>> package already the does not depend on the management impl I did not
>> move them but they would be better placed in api.management.events.
>>
>> Christian
>>
>>
>>
>>
>> Am 24.08.2011 19:12, schrieb Claus Ibsen:
>>> On Wed, Aug 24, 2011 at 6:17 PM, Christian Schneider
>>> <ch...@die-schneider.net> 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) and HashMap (Impl) are both in java.util package.
>>>
>>> However these annotations are not regular interfaces, that end users
>>> is supposed to implement.
>>> Or for example that we in the Apache Camel provides 2+ different
>>> implements of those annotations.
>>>
>>> As an end user I would feel natural these annotations are in the
>>> mangement package as they are part of the management
>>> (end user) API in Camel.
>>>
>>>
>>> The Spring framework put these annotations at
>>> http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/jmx/export/annotation/ManagedOperation.html 
>>>
>>>
>>>
>>> We could also have a annotation subpackage
>>> (org.apache.camel.management.annotation)
>>> but we usually dont have that, eg there are no annotation package for
>>> @Consume, @Produce, @EndpointInject etc.
>>>
>>> Alternatively we could move them in the root package, but as you said
>>> there is already plenty of APIs in that package.
>>>
>>> Putting them in org.apache.camel.api seems a bit weird, as they would
>>> be the only pieces in there.
>>> And for Camel 2.x we should keep the API stable and not move around
>>> stuff all the time.
>>>
>>>
>>>
>>>> Christian
>>>>
>>>>
>>>> Am 24.08.2011 17:53, schrieb Claus Ibsen:
>>>>> On Wed, Aug 24, 2011 at 3:04 PM, Christian Schneider
>>>>> <ch...@die-schneider.net> 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 in Camel and IMHO
>>>>> should be in that package.
>>>>>
>>>>>
>>>>>
>>>>>> 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 it clearer but that
>>>>>> will
>>>>>> probably create too much incompatibility.
>>>>>>
>>>>>> Christian
>>>>>>
>>>>>>
>>>>>> Am 24.08.2011 14:13, schrieb Claus Ibsen:
>>>>>>> On Tue, Aug 23, 2011 at 12:38 PM, Christian Schneider
>>>>>>> <ch...@die-schneider.net> 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
>>>>>>>> framework. So API interfaces are implemented by the framework. SPI
>>>>>>>> interfaces are implemented by the user to change functionality of
>>>>>>>> the
>>>>>>>> framework or for callbacks
>>>>>>>> 2) SPI interfaces are for third party modules while API
>>>>>>>> interfaces are
>>>>>>>> for
>>>>>>>> users
>>>>>>>>
>>>>>>>> So the current case for me is the new JMX annotations. Are they 
>>>>>>>> SPI
>>>>>>>> interfaces or API interfaces?
>>>>>>>>
>>>>>>> They are API interfaces. Just like @Consumer, @Produce and any 
>>>>>>> of the
>>>>>>> other API Camel annotations we have.
>>>>>>> Its just that these annotations is for management enabling your
>>>>>>> business logic / custom components or whatnot.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> So what is your opinion about the specific and the general case.
>>>>>>>>
>>>>>>>> As a side question: The org.apache.camel package has grown quite
>>>>>>>> large.
>>>>>>>> I
>>>>>>>> think we should create specialized packages for it. As we are
>>>>>>>> talking
>>>>>>>> about
>>>>>>>> the camel API org.apache.camel.api.* would be a good name in my
>>>>>>>> opinion.
>>>>>>>> So
>>>>>>>> the questions are: Should we create such specialized packages?
>>>>>>>> Should
>>>>>>>> we
>>>>>>>> move API parts there? Should we only use the new packages for new
>>>>>>>> stuff?
>>>>>>>>
>>>>>>>> Christian
>>>>>>>>
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> -- 
>>>>>>>> Christian Schneider
>>>>>>>> http://www.liquid-reality.de
>>>>>>>>
>>>>>>>> Open Source Architect
>>>>>>>> Talend Application Integration Division http://www.talend.com
>>>>>>>>
>>>>>>>>
>>>>>> -- 
>>>>>> -- 
>>>>>> Christian Schneider
>>>>>> http://www.liquid-reality.de
>>>>>>
>>>>>> Open Source Architect
>>>>>> Talend Application Integration Division http://www.talend.com
>>>>>>
>>>>>>
>>>>>
>>>> -- 
>>>> Christian Schneider
>>>> http://www.liquid-reality.de
>>>>
>>>> Open Source Architect
>>>> http://www.talend.com
>>>>
>>>>
>>>
>>>
>>
>


-- 
--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: Scope of org.apache.camel.spi

Posted by Hadrian Zbarcea <hz...@gmail.com>.
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, Christian Schneider wrote:
> 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.
>
> In spring I suspect it is on purpose. They could provide API jars that
> make you independent of their implementation. By combining API and impl
> they force you into having a hard dependency on spring.
> You had to remove the spring JMX annotations as we did not want to have
> their impl. If they had cleanly separated their API from the impl we
> could have kept the one API jar with the annotations and just
> implemented them ourself when running outside of spring.
>
> So having the annotations in the management package is a very bad idea.
> A subpackage would work on a pure simple package perspective but I think
> it would be bad to have a top level package with implementations and a
> subpackage with the API.
>
> We can move around the management stuff at the moment as my commit
> changed it anyway. So before Camel 2.9 comes out we are free to move them.
>
> api.management of course only makes sense if we intend to put more stuff
> there but I think it would be a good idea to do so.
> Having a top level api package will also make it easier to create a pure
> API jar for camel 3.0. I think it would be strange if the API jar would
> contain
>
> org.apache.camel
> org.apache.camel.spi
> org.apache.camel.management.annotation
>
> but not
> org.apache.camel.management
>
> Btw management.annotation is not enough anyway as we have more
> management interfaces that have to live in the API space. So
> management.api would be better but I would prefer to have api at the top
> level so the user can clearly see that everything api.* is part of the API.
>
> In any case we need to separate the management API from the management
> impl classes. If we do not do it then we have no chance to avoid cycles.
> Besides that how should we make it possible that the components only
> need to depend on the API if we mix things. For example a component may
> want to use the management annotations or another management interface
> but it should not know the impl.
>
> Btw. the event classes should also be part of the API as they are
> necessary to understand management events. As they live in a separate
> package already the does not depend on the management impl I did not
> move them but they would be better placed in api.management.events.
>
> Christian
>
>
>
>
> Am 24.08.2011 19:12, schrieb Claus Ibsen:
>> On Wed, Aug 24, 2011 at 6:17 PM, Christian Schneider
>> <ch...@die-schneider.net> 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) and HashMap (Impl) are both in java.util package.
>>
>> However these annotations are not regular interfaces, that end users
>> is supposed to implement.
>> Or for example that we in the Apache Camel provides 2+ different
>> implements of those annotations.
>>
>> As an end user I would feel natural these annotations are in the
>> mangement package as they are part of the management
>> (end user) API in Camel.
>>
>>
>> The Spring framework put these annotations at
>> http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/jmx/export/annotation/ManagedOperation.html
>>
>>
>> We could also have a annotation subpackage
>> (org.apache.camel.management.annotation)
>> but we usually dont have that, eg there are no annotation package for
>> @Consume, @Produce, @EndpointInject etc.
>>
>> Alternatively we could move them in the root package, but as you said
>> there is already plenty of APIs in that package.
>>
>> Putting them in org.apache.camel.api seems a bit weird, as they would
>> be the only pieces in there.
>> And for Camel 2.x we should keep the API stable and not move around
>> stuff all the time.
>>
>>
>>
>>> Christian
>>>
>>>
>>> Am 24.08.2011 17:53, schrieb Claus Ibsen:
>>>> On Wed, Aug 24, 2011 at 3:04 PM, Christian Schneider
>>>> <ch...@die-schneider.net> 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 in Camel and IMHO
>>>> should be in that package.
>>>>
>>>>
>>>>
>>>>> 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 it clearer but that
>>>>> will
>>>>> probably create too much incompatibility.
>>>>>
>>>>> Christian
>>>>>
>>>>>
>>>>> Am 24.08.2011 14:13, schrieb Claus Ibsen:
>>>>>> On Tue, Aug 23, 2011 at 12:38 PM, Christian Schneider
>>>>>> <ch...@die-schneider.net> 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
>>>>>>> framework. So API interfaces are implemented by the framework. SPI
>>>>>>> interfaces are implemented by the user to change functionality of
>>>>>>> the
>>>>>>> framework or for callbacks
>>>>>>> 2) SPI interfaces are for third party modules while API
>>>>>>> interfaces are
>>>>>>> for
>>>>>>> users
>>>>>>>
>>>>>>> So the current case for me is the new JMX annotations. Are they SPI
>>>>>>> interfaces or API interfaces?
>>>>>>>
>>>>>> They are API interfaces. Just like @Consumer, @Produce and any of the
>>>>>> other API Camel annotations we have.
>>>>>> Its just that these annotations is for management enabling your
>>>>>> business logic / custom components or whatnot.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> So what is your opinion about the specific and the general case.
>>>>>>>
>>>>>>> As a side question: The org.apache.camel package has grown quite
>>>>>>> large.
>>>>>>> I
>>>>>>> think we should create specialized packages for it. As we are
>>>>>>> talking
>>>>>>> about
>>>>>>> the camel API org.apache.camel.api.* would be a good name in my
>>>>>>> opinion.
>>>>>>> So
>>>>>>> the questions are: Should we create such specialized packages?
>>>>>>> Should
>>>>>>> we
>>>>>>> move API parts there? Should we only use the new packages for new
>>>>>>> stuff?
>>>>>>>
>>>>>>> Christian
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> --
>>>>>>> Christian Schneider
>>>>>>> http://www.liquid-reality.de
>>>>>>>
>>>>>>> Open Source Architect
>>>>>>> Talend Application Integration Division http://www.talend.com
>>>>>>>
>>>>>>>
>>>>> --
>>>>> --
>>>>> Christian Schneider
>>>>> http://www.liquid-reality.de
>>>>>
>>>>> Open Source Architect
>>>>> Talend Application Integration Division http://www.talend.com
>>>>>
>>>>>
>>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
>>>
>>
>>
>

Re: Scope of org.apache.camel.spi

Posted by Christian Schneider <ch...@die-schneider.net>.
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.

In spring I suspect it is on purpose. They could provide API jars that 
make you independent of their implementation. By combining API and impl 
they force you into having a hard dependency on spring.
You had to remove the spring JMX annotations as we did not want to have 
their impl. If they had cleanly separated their API from the impl we 
could have kept the one API jar with the annotations and just 
implemented them ourself when running outside of spring.

So having the annotations in the management package is a very bad idea. 
A subpackage would work on a pure simple package perspective but I think 
it would be bad to have a top level package with implementations and a 
subpackage with the API.

We can move around the management stuff at the moment as my commit 
changed it anyway. So before Camel 2.9 comes out we are free to move them.

api.management of course only makes sense if we intend to put more stuff 
there but I think it would be a good idea to do so.
Having a top level api package will also make it easier to create a pure 
API jar for camel 3.0. I think it would be strange if the API jar would 
contain

org.apache.camel
org.apache.camel.spi
org.apache.camel.management.annotation

but not
org.apache.camel.management

Btw management.annotation is not enough anyway as we have more 
management interfaces that have to live in the API space. So 
management.api would be better but I would prefer to have api at the top 
level so the user can clearly see that everything api.* is part of the API.

In any case we need to separate the management API from the management 
impl classes. If we do not do it then we have no chance to avoid cycles. 
Besides that how should we make it possible that the components only 
need to depend on the API if we mix things. For example a component may 
want to use the management annotations or another management interface 
but it should not know the impl.

Btw. the event classes should also be part of the API as they are 
necessary to understand management events. As they live in a separate 
package already the does not depend on the management impl I did not 
move them but they would be better placed in api.management.events.

Christian




Am 24.08.2011 19:12, schrieb Claus Ibsen:
> On Wed, Aug 24, 2011 at 6:17 PM, Christian Schneider
> <ch...@die-schneider.net>  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) and HashMap (Impl) are both in java.util package.
>
> However these annotations are not regular interfaces, that end users
> is supposed to implement.
> Or for example that we in the Apache Camel provides 2+ different
> implements of those annotations.
>
> As an end user I would feel natural these annotations are in the
> mangement package as they are part of the management
> (end user) API in Camel.
>
>
> The Spring framework put these annotations at
> http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/jmx/export/annotation/ManagedOperation.html
>
> We could also have a annotation subpackage
> (org.apache.camel.management.annotation)
> but we usually dont have that, eg there are no annotation package for
> @Consume, @Produce, @EndpointInject etc.
>
> Alternatively we could move them in the root package, but as you said
> there is already plenty of APIs in that package.
>
> Putting them in org.apache.camel.api seems a bit weird, as they would
> be the only pieces in there.
> And for Camel 2.x we should keep the API stable and not move around
> stuff all the time.
>
>
>
>> Christian
>>
>>
>> Am 24.08.2011 17:53, schrieb Claus Ibsen:
>>> On Wed, Aug 24, 2011 at 3:04 PM, Christian Schneider
>>> <ch...@die-schneider.net>    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 in Camel and IMHO
>>> should be in that package.
>>>
>>>
>>>
>>>> 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 it clearer but that will
>>>> probably create too much incompatibility.
>>>>
>>>> Christian
>>>>
>>>>
>>>> Am 24.08.2011 14:13, schrieb Claus Ibsen:
>>>>> On Tue, Aug 23, 2011 at 12:38 PM, Christian Schneider
>>>>> <ch...@die-schneider.net>      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
>>>>>> framework. So API interfaces are implemented by the framework. SPI
>>>>>> interfaces are implemented by the user to change functionality of the
>>>>>> framework or for callbacks
>>>>>> 2) SPI interfaces are for third party modules while API interfaces are
>>>>>> for
>>>>>> users
>>>>>>
>>>>>> So the current case for me is the new JMX annotations. Are they SPI
>>>>>> interfaces or API interfaces?
>>>>>>
>>>>> They are API interfaces. Just like @Consumer, @Produce and any of the
>>>>> other API Camel annotations we have.
>>>>> Its just that these annotations is for management enabling your
>>>>> business logic / custom components or whatnot.
>>>>>
>>>>>
>>>>>
>>>>>> So what is your opinion about the specific and the general case.
>>>>>>
>>>>>> As a side question: The org.apache.camel package has grown quite large.
>>>>>> I
>>>>>> think we should create specialized packages for it. As we are talking
>>>>>> about
>>>>>> the camel API org.apache.camel.api.* would be a good name in my
>>>>>> opinion.
>>>>>> So
>>>>>> the questions are: Should we create such specialized packages? Should
>>>>>> we
>>>>>> move API parts there? Should we only use the new packages for new
>>>>>> stuff?
>>>>>>
>>>>>> Christian
>>>>>>
>>>>>>
>>>>>> --
>>>>>> --
>>>>>> Christian Schneider
>>>>>> http://www.liquid-reality.de
>>>>>>
>>>>>> Open Source Architect
>>>>>> Talend Application Integration Division http://www.talend.com
>>>>>>
>>>>>>
>>>> --
>>>> --
>>>> Christian Schneider
>>>> http://www.liquid-reality.de
>>>>
>>>> Open Source Architect
>>>> Talend Application Integration Division http://www.talend.com
>>>>
>>>>
>>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
>>
>
>

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: Scope of org.apache.camel.spi

Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Aug 24, 2011 at 6:17 PM, Christian Schneider
<ch...@die-schneider.net> 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) and HashMap (Impl) are both in java.util package.

However these annotations are not regular interfaces, that end users
is supposed to implement.
Or for example that we in the Apache Camel provides 2+ different
implements of those annotations.

As an end user I would feel natural these annotations are in the
mangement package as they are part of the management
(end user) API in Camel.


The Spring framework put these annotations at
http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/jmx/export/annotation/ManagedOperation.html

We could also have a annotation subpackage
(org.apache.camel.management.annotation)
but we usually dont have that, eg there are no annotation package for
@Consume, @Produce, @EndpointInject etc.

Alternatively we could move them in the root package, but as you said
there is already plenty of APIs in that package.

Putting them in org.apache.camel.api seems a bit weird, as they would
be the only pieces in there.
And for Camel 2.x we should keep the API stable and not move around
stuff all the time.



> Christian
>
>
> Am 24.08.2011 17:53, schrieb Claus Ibsen:
>>
>> On Wed, Aug 24, 2011 at 3:04 PM, Christian Schneider
>> <ch...@die-schneider.net>  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 in Camel and IMHO
>> should be in that package.
>>
>>
>>
>>> 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 it clearer but that will
>>> probably create too much incompatibility.
>>>
>>> Christian
>>>
>>>
>>> Am 24.08.2011 14:13, schrieb Claus Ibsen:
>>>>
>>>> On Tue, Aug 23, 2011 at 12:38 PM, Christian Schneider
>>>> <ch...@die-schneider.net>    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
>>>>> framework. So API interfaces are implemented by the framework. SPI
>>>>> interfaces are implemented by the user to change functionality of the
>>>>> framework or for callbacks
>>>>> 2) SPI interfaces are for third party modules while API interfaces are
>>>>> for
>>>>> users
>>>>>
>>>>> So the current case for me is the new JMX annotations. Are they SPI
>>>>> interfaces or API interfaces?
>>>>>
>>>> They are API interfaces. Just like @Consumer, @Produce and any of the
>>>> other API Camel annotations we have.
>>>> Its just that these annotations is for management enabling your
>>>> business logic / custom components or whatnot.
>>>>
>>>>
>>>>
>>>>> So what is your opinion about the specific and the general case.
>>>>>
>>>>> As a side question: The org.apache.camel package has grown quite large.
>>>>> I
>>>>> think we should create specialized packages for it. As we are talking
>>>>> about
>>>>> the camel API org.apache.camel.api.* would be a good name in my
>>>>> opinion.
>>>>> So
>>>>> the questions are: Should we create such specialized packages? Should
>>>>> we
>>>>> move API parts there? Should we only use the new packages for new
>>>>> stuff?
>>>>>
>>>>> Christian
>>>>>
>>>>>
>>>>> --
>>>>> --
>>>>> Christian Schneider
>>>>> http://www.liquid-reality.de
>>>>>
>>>>> Open Source Architect
>>>>> Talend Application Integration Division http://www.talend.com
>>>>>
>>>>>
>>>>
>>>
>>> --
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> Talend Application Integration Division http://www.talend.com
>>>
>>>
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Scope of org.apache.camel.spi

Posted by Christian Schneider <ch...@die-schneider.net>.
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
> <ch...@die-schneider.net>  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 in Camel and IMHO
> should be in that package.
>
>
>
>> 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 it clearer but that will
>> probably create too much incompatibility.
>>
>> Christian
>>
>>
>> Am 24.08.2011 14:13, schrieb Claus Ibsen:
>>> On Tue, Aug 23, 2011 at 12:38 PM, Christian Schneider
>>> <ch...@die-schneider.net>    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
>>>> framework. So API interfaces are implemented by the framework. SPI
>>>> interfaces are implemented by the user to change functionality of the
>>>> framework or for callbacks
>>>> 2) SPI interfaces are for third party modules while API interfaces are
>>>> for
>>>> users
>>>>
>>>> So the current case for me is the new JMX annotations. Are they SPI
>>>> interfaces or API interfaces?
>>>>
>>> They are API interfaces. Just like @Consumer, @Produce and any of the
>>> other API Camel annotations we have.
>>> Its just that these annotations is for management enabling your
>>> business logic / custom components or whatnot.
>>>
>>>
>>>
>>>> So what is your opinion about the specific and the general case.
>>>>
>>>> As a side question: The org.apache.camel package has grown quite large. I
>>>> think we should create specialized packages for it. As we are talking
>>>> about
>>>> the camel API org.apache.camel.api.* would be a good name in my opinion.
>>>> So
>>>> the questions are: Should we create such specialized packages? Should we
>>>> move API parts there? Should we only use the new packages for new stuff?
>>>>
>>>> Christian
>>>>
>>>>
>>>> --
>>>> --
>>>> Christian Schneider
>>>> http://www.liquid-reality.de
>>>>
>>>> Open Source Architect
>>>> Talend Application Integration Division http://www.talend.com
>>>>
>>>>
>>>
>>
>> --
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>>
>
>

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: Scope of org.apache.camel.spi

Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Aug 24, 2011 at 3:04 PM, Christian Schneider
<ch...@die-schneider.net> 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 in Camel and IMHO
should be in that package.



> 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 it clearer but that will
> probably create too much incompatibility.
>
> Christian
>
>
> Am 24.08.2011 14:13, schrieb Claus Ibsen:
>>
>> On Tue, Aug 23, 2011 at 12:38 PM, Christian Schneider
>> <ch...@die-schneider.net>  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
>>> framework. So API interfaces are implemented by the framework. SPI
>>> interfaces are implemented by the user to change functionality of the
>>> framework or for callbacks
>>> 2) SPI interfaces are for third party modules while API interfaces are
>>> for
>>> users
>>>
>>> So the current case for me is the new JMX annotations. Are they SPI
>>> interfaces or API interfaces?
>>>
>> They are API interfaces. Just like @Consumer, @Produce and any of the
>> other API Camel annotations we have.
>> Its just that these annotations is for management enabling your
>> business logic / custom components or whatnot.
>>
>>
>>
>>> So what is your opinion about the specific and the general case.
>>>
>>> As a side question: The org.apache.camel package has grown quite large. I
>>> think we should create specialized packages for it. As we are talking
>>> about
>>> the camel API org.apache.camel.api.* would be a good name in my opinion.
>>> So
>>> the questions are: Should we create such specialized packages? Should we
>>> move API parts there? Should we only use the new packages for new stuff?
>>>
>>> Christian
>>>
>>>
>>> --
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> Talend Application Integration Division http://www.talend.com
>>>
>>>
>>
>>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Scope of org.apache.camel.spi

Posted by Christian Schneider <ch...@die-schneider.net>.
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 it clearer but 
that will probably create too much incompatibility.

Christian


Am 24.08.2011 14:13, schrieb Claus Ibsen:
> On Tue, Aug 23, 2011 at 12:38 PM, Christian Schneider
> <ch...@die-schneider.net>  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
>> framework. So API interfaces are implemented by the framework. SPI
>> interfaces are implemented by the user to change functionality of the
>> framework or for callbacks
>> 2) SPI interfaces are for third party modules while API interfaces are for
>> users
>>
>> So the current case for me is the new JMX annotations. Are they SPI
>> interfaces or API interfaces?
>>
> They are API interfaces. Just like @Consumer, @Produce and any of the
> other API Camel annotations we have.
> Its just that these annotations is for management enabling your
> business logic / custom components or whatnot.
>
>
>
>> So what is your opinion about the specific and the general case.
>>
>> As a side question: The org.apache.camel package has grown quite large. I
>> think we should create specialized packages for it. As we are talking about
>> the camel API org.apache.camel.api.* would be a good name in my opinion. So
>> the questions are: Should we create such specialized packages? Should we
>> move API parts there? Should we only use the new packages for new stuff?
>>
>> Christian
>>
>>
>> --
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>>
>
>


-- 
--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: Scope of org.apache.camel.spi

Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Aug 23, 2011 at 12:38 PM, Christian Schneider
<ch...@die-schneider.net> 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
> framework. So API interfaces are implemented by the framework. SPI
> interfaces are implemented by the user to change functionality of the
> framework or for callbacks
> 2) SPI interfaces are for third party modules while API interfaces are for
> users
>
> So the current case for me is the new JMX annotations. Are they SPI
> interfaces or API interfaces?
>

They are API interfaces. Just like @Consumer, @Produce and any of the
other API Camel annotations we have.
Its just that these annotations is for management enabling your
business logic / custom components or whatnot.



> So what is your opinion about the specific and the general case.
>
> As a side question: The org.apache.camel package has grown quite large. I
> think we should create specialized packages for it. As we are talking about
> the camel API org.apache.camel.api.* would be a good name in my opinion. So
> the questions are: Should we create such specialized packages? Should we
> move API parts there? Should we only use the new packages for new stuff?
>
> Christian
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/