On Sat, 2003-08-16 at 19:19, Jason van Zyl wrote: > 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. That would be great!
> > > 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. Sounds good! Looking forward to using it! > > > 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. I hope you write the book, maven is a really awesome technology that could use a full book to help new users. > > > -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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
