On Sat, 2003-08-16 at 16:35, 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. 

Ok, that I don't quite understand. There is just a fear of polluting the
classpath?

> 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?

Yes, if you override the version of an artifact at build.properties
level you can control the versioning. This mechanism is far from perfect
and doesn't work because of some inheritance problems in general, in
this particular case properties. The code in HEAD deals with this much
better but is not for general consumption at the moment.

> 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.

It shouldn't be. I intentionally made the xdoc plugin to work with the
resultant POM after any transformations due to inheritance and/or
interpolation. If this is not the case now then someone whacked it.

I just actually checked with a component that inherits and the inherited
dependencies do indeed show up in the dependency report.

> Luke.
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to