Thanks for the reply and excellent clarification. Instead of OSGi bundle
just think JAR. I have the structure that you suggested except that I
did not use an assembly because I could not see how to create a JAR that
only contained the contents of I and P and not all of their dependencies.
To clarify what I am trying to do I will extend your example.
In the following A1 and A2 are general artifacts, B and C are
'subsystems' that each create a single JAR artifact from their nested
modules. The nested modules each create a JAR artifact, e.g. B-I, B-P,
C-I, C-P.
-- A1
-- A2
-- B
+-- pom.xml
|
+-- I
+-- pom.xml
+-- src (depends on A1)
+-- P
+-- pom.xml
+-- src (depends on B-I)
-- C
+-- pom.xml
|
+-- I
+-- pom.xml
+-- src
+-- P
+-- pom.xml
+-- src (depends on A2, B-I, C-I)
+-- test (depends on B-P)
To summarize.
B API (B-I) depends on artifact A1. B implementation (B-P) depends on
the B API (obviously) and transitively on artifact A1.
C API (C-I) does not depend on anything. But C implementation (C-P)
depends on artifact A2 as well as APIs for B (B-I) and C (C-I) and
transitively on artifact A1.
Running of the C implementation tests also has a dependency on B-P but
compiling of the tests does not.
I can easily create a JAR for B and C (I wrote a little plugin that
aggregates the classes / resources from children into the parent and
then use normal plugins to package it up). The problem is sorting out
the dependencies. In the above example the aggregated JAR for B should
be dependent on A1 and the aggregated JAR for C should be dependent on
A2 and the aggregated JAR for B. Unfortunately, I cannot see how I can
modify the dependencies on the fly in order to produce that result.
What I would like to do is create an assembly from the aggregated JARs
and have that assembly automatically contain the transitive
dependencies, e.g. in the above example I would like an assembly with B,
C, A1 and A2 but not B-I, B-P, C-I or C-P. If I cannot sort out the
dependencies then I lose one big advantage of Maven over out build which
is transitive dependency support.
The above approach will give me compile time protection against using
implementation classes directly and OSGi will give me runtime
protection. But it is not perfect because if someone compiles against
the aggregated JAR then they could still use the implementation classes
even though it would fail at runtime.
If the above is not possible then I was wondering whether there was any
tool out there that would detect when classes were using 'implementation
classes', e.g. by marking API packages with a Java 1.5 annotation and
then doing some form of byte code analysis to detect whether a class is
using non API classes from other artifacts?
Insitu wrote:
Paul Duffin <[EMAIL PROTECTED]> writes:
I have been looking at having separate poms for API and implementation
and bundle. I can build the bundle (just think JAR if you don't know
what that is) by aggregating the classes/resources from the API and
implementation into one directory and then using standard plugins to
create it. The problem I have with this is that while building I want
to have dependencies on the API poms (as the Java compiler does not
know about OSGi bundle exports) but when installing and running I want
to have dependencies on the bundle.
Does anyone else use this sort of structure, if so how do you manage
this in Maven ?
Is there anyway to do what I want ?
Hello,
I am not sure I fully understand your problem, and I am not familiar
with OSGi bundles, so let me rephrase it:
- you have a component C that is broken down into an interface I and
an implementation P. You only need I at compile time but need P at
runtime.
- from a maven perspective, this would mean that you would have
astructure like that
-- C
+-- pom.xml
|
+-- I
+-- pom.xml
+-- src ....
+-- P
+-- pom.xml
+-- src
+-- src/main/assembly ...
Then I would configure C to build:
- I as a standard artifact deployed in a "public" repo: Other
projects would then be allowed to depend on it
- P as a standard artifact but deployed in a "private" repo not
available outside the team producing it
- C as a pom and with an OSGi bundle (what I call assembly above)
deployed and available publicly.
Then client components/programs could depend on I for compiling and on
C's bundle for running, using a profile.
HTH
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
