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
