maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Libbrecht <>
Subject Re: project.xml is a jelly script?
Date Sat, 16 Aug 2003 21:17:08 GMT
Is the idea of a dependency role not something that would possibly help 
here ?

Aside of basic-roles like "building", "running-tests", etc, a project 
should even be able to specify roles depending on the runtime behaviour 

Dependency inclusion (which is planned in some maven future I thought) 
could then be extended to respect this role.

This doesn't answer, however, a possible attribute like "dependency on 
xxx version a to b" which was alluded first.


Luke Taylor wrote:
> Jason van Zyl wrote:
>> Dependencies are inherited in an aggregate fashion. So if you have
>> common dependencies then you can state them in a parent project. In much
>> the same way the Jelly tag builds are setup.
>>> I did not wish to put all of the depends into a parent project as 
>>> that would force each child project to have additional dependencies 
>>> on its classpath which might not be a good thing, nor do I want each 
>>> and every module to try to download SNAPSHOTS, especially if they do 
>>> not even need that depend.
>> Sorry, don't understand that one. You want a common set of dependencies
>> but don't want them in the classpath? What do you want to use those
>> common dependencies for?
> I think the problem is that you might want to put shared dependencies 
> into a parent project file for a reactor project which has, for example, 
> 20 sub-projects/components. But if perhaps only 10 of them actually use 
> the dependencies, they will still have to be available for building the 
> others individually. Of course, you can specify the dependencies 
> individually in each component but then you have to maintain all the 
> versions separately even though you want to use the same version 
> throughout. Does the standard artifact version stuff you mentioned cover 
> this scenario?
> The dependency list is also useful high-level documentation on what is 
> required for each component and how it works, but this information is 
> lost if it is put in the parent file.
> Luke.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message