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
eventually we could have
org.apache.camel.management.api.annotations
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.
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
