On Sat, 2003-08-16 at 16:35, Luke Taylor wrote:I can't speak for the Geronimo project. From my point of view it's not a huge issue (downloading extra jars certainly isn't a problem), but I prefer to see the dependencies listed per-component. The version properties you mentioned will probably allow that without any problems.
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?
OK, great. That sounds pretty useful. So you don't have to specify your own version properties. Does that follow a kind of
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.
<group>.<artifactId>.<version>
syntax?
I realise inheritance of properties is still a bit hosed. If it will work at some stage then that's worth knowing :).
OK, slight misunderstanding. I shouldn't have said that the info is "lost". I meant that the global dependencies will show up as requirements for all the components, rather than just those to which they actually apply. So the detail is "lost" rather than the actual information - all you know is that a subset of the components use the dependencies in the root POM.
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.
Thanks,
Luke.
-- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523C http://www.monkeymachine.ltd.uk
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
