My group is currently running into the same problem.What we are doing is declaring all our system/lib jars in a projects.xml which all our projects extend. This is nice in respect to ensure that everyone is building/debugging against the libraries that are in production. We are actually using this parent project.xml to document our system configuration.
The problem we run into is that, like stated earlier in this thread, we lose on the meaningfulness of the dependencies documentation in all the projects that extend the parent project.xml. Our system library has 50 jars and many of our application are only using a handful more then the standard java server libraries. Another concept that we think would be a good feature of maven is the ability to state a group of dependencies, say struts and all it's libraries. This would be stated in a xml file that declares all the jars that struts uses. This xml file could be stored in the maven central repository so that projects that want to use struts 1.1 and all related libraries could declare (maybe call it a "group dependency") this file in it's project.xml and when doing builds maven would pull down the struts dependency list and then check if those libraries have been downloaded to the developers local repository.We tend to use frameworks that consist of 5+ libraries which all depend on each other.Managing dependencies through "groups" of libraries would ease setting up new projects, and give more structure to dependencies. I'm not sure of how hard this would be to implement, whether it would be to hack the project.xml or go directly into the maven impl??? I'd be willing to work on this functionality if others (committers +) thought this was a good idea/approach. -Mark On Sat, 2003-08-16 at 14:17, Paul Libbrecht wrote: > 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 > expected. > > 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. > > Paul > > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
