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: 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/
