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/
