maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Helck" <Chris.He...@us.icap.com>
Subject RE: Re: Replacing Proprietary Build System With Maven
Date Thu, 27 Sep 2007 16:06:54 GMT
Could this be done with the <exclude> tag in <dependency>? You would exclude B-I
and B-P.
-chris 

-----Original Message-----
From: news [mailto:news@sea.gmane.org] On Behalf Of Insitu
Sent: Thursday, September 27, 2007 10:56 AM
To: users@maven.apache.org
Subject: Re: Replacing Proprietary Build System With Maven

>
> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


**********************************************************************
This communication and all information (including, but not limited to,
 market prices/levels and data) contained therein (the "Information") is
 for informational purposes only, is confidential, may be legally
 privileged and is the intellectual property of ICAP plc and its affiliates
 ("ICAP") or third parties. No confidentiality or privilege is waived or
 lost by any mistransmission. The Information is not, and should not
 be construed as, an offer, bid or solicitation in relation to any
 financial instrument or as an official confirmation of any transaction.
 The Information is not warranted, including, but not limited, as to
 completeness, timeliness or accuracy and is subject to change
 without notice. ICAP assumes no liability for use or misuse of the
 Information. All representations and warranties are expressly
 disclaimed. The Information does not necessarily reflect the views of
 ICAP. Access to the Information by anyone else other than the
 recipient is unauthorized and any disclosure, copying, distribution or
 any action taken or omitted to be taken in reliance on it is prohibited. If
 you receive this message in error, please immediately delete it and all
 copies of it from your system, destroy any hard copies of it and
 notify the sender.
**********************************************************************


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message