> > 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? >
If I resummarize, what you want is that building the whole project creates a bundle containing B, C and their transitive dependencies, but not the submodules of B and C. I am pretty sure assembly+dependency could do the trick. Give me a little bit time (one or 2 days) and I will send you a skeleton project doing this (or I will confess miserably my incompetence :)). Or maybe you have that skeleton, a stripped/anonymized version of your project to start with ? Or someone else on the list already has the answer... Best regards, --- OQube < software engineering \ génie logiciel > Arnaud Bailly, Dr. \web> http://www.oqube.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
