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.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
