Damien,
Thanks very much for all your help. That is very similar to what I
want to do. The use of <scope>provided</scope> is probably the bit I was
missing but I just need to check that it will work as I think it does.
The majority of my OSGi bundles don't yet provide a service (although
they will eventually), I am just porting them from a non OSGi
environment in which we typically used reflection to load an
implementation of a factory (defined in the API). That means that they
typically pack the API and SP together.
Just to clarify, the API artifact is a normal JAR that contains the API
classes. The SP artifact is an OSGi bundle that contains both the API
and the SP classes. It uses the <Embed-Dependency> instruction from the
felix bundle plugin to include the API (selected using package). The
<scope>provided</scope> will hide the dependency between the bundle and
the seperate API artifact.
I presume that for testing the SC you have a dependency on the SP/API
bundle artifact. How do you test the SC, inside an OSGi container or
within unit tests ? If the latter how do you do it, do you mock up an
OSGi container, break encapsulation and create the service directly,
mock up the service ?
Do you do also have a runtime dependency between SC and SP/API ? I know
you don't need one as the SC can use any relevant service.
How do you assemble your application ?
Damien Lecan wrote:
Could you give me an example of how you separate your API and
implementation. Do you use separate poms, or within the same pom ? If
within the same pom how do you check that only the API is used by other
poms ? If in separate poms how do you build the bundle ?
There are 2 things in your questions :
- how am I deploying my OSGi applications
- how am I building my OSGi bundles
The second question depends on the 1st one.
With OSGi, you can choose where you want to deploy java classes. I can
reduce an OSGi application to 3 components :
- service consumers (SC)
- service descriptions (API)
- service producers (SP)
Dependencies :
SC -> API <- SP
Many packaging solutions can found : all together or each component in
its own bundle.
Ok, packaging SC + API together is a bad idea, but packaging API + SP
can be done.
This last solution is a problem only when you can have several SP for
the same API.
So, basicaly, I have :
Parent pom
+- SC (depends on API with scope "provided")
+-API
+-SP (depends on API, can embed API if API scope is "compile")
If you want 3 bundles, don't embed API in SP
If you want 2 bundles, embed API in SP (just a pom configuration)
Is it what you want ?
Damien Lecan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
