On Sat, 2003-08-16 at 12:11, Mark McBride wrote: > 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.
What if in the reports you could distinguish between the dependencies stated for the project directly versus those that are inherited? This could generalized and methods in the POM could be added to select the stated versus inherited dependencies. > 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 actually works in the maven-new code where you do this by stating a POM of another project as a dependency. And transitive dependencies also work in maven-new. I've just had zero time of late. > 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. This is what we are trying to achieve by starting to store POMs for projects in the repository. As mentioned before, having POM dependencies and transitive dependencies isn't a technical problem it's getting all the POMs into the 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. What you want is transitive dependencies. It's coming, well the code actaully exists it's a matter of merging it. > 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. It is a good idea and already works but the code is splayed between what's now in HEAD and what's in maven-new. I'm in the process of starting a new business but once the infrastructure is done I plan to take a little Maven vacation. There is certainly nothing more I would like to do than get all the code merged so users can take advantage of it. My committment hasn't waned I am just at a critical stage in a new endeavour and it takes priority. One thing that I'm hoping will force me to complete things is the writing of a book on Maven. I have only chatted with some folks at O'Reilly and there is by no means anything even remotely certain but I'm hoping I can convince them to let me right a book with the help of a couple other folks. I'm hoping for the best. > -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] -- 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]
