Re: Scope of org.apache.camel.spi
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
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: cib...@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
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: cib...@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
...@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: cib...@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: cib...@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
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
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
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: cib...@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
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
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: cib...@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
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.netwrote: 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
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: cib...@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
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.netwrote: 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
Re: Scope of org.apache.camel.spi
, 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
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
