camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <hzbar...@gmail.com>
Subject Re: Scope of org.apache.camel.spi
Date Wed, 24 Aug 2011 21:45:27 GMT
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
>> <chris@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
>>>> <chris@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
>>>>>> <chris@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
>>>
>>>
>>
>>
>

Mime
View raw message