The side effects I am aware of are: 1. Someone already specified a pom as a dependency in dependencyManagement (I can't imagine why, but it is possible). This was mitigated by using <scope>import</scope>.
2. <scope>import</scope> could be used on a dependency in dependencyManagement that is not a pom. The code detects that and generates an error. 3. <scope>import</scope> could be used outside of dependencyManagement. Maven currently doesn't do any enforcement of valid values for scope. If someone tried to do this it would be invalid (and be treated as it currently would be) since that code has no idea what to do with that scope. 4. Multiple poms being included might declare the same dependency. The code currently uses either the one found in the pom doing the import or in the first imported pom to declare it. It has been suggested to me that perhaps this situation should just generate an error. I'd be happy to change it to do that or to use a property to control the behavior. This is all that I am aware of. Ralph Brian E. Fox said: > I need to think about this some more, but at first blush it could be > useful. I need to think about any possible side effects. > > -----Original Message----- > From: Ralph Goers [mailto:[EMAIL PROTECTED] > Sent: Friday, October 19, 2007 11:08 AM > To: Maven Developers List > Subject: Re: [codehaus-confluence] Maven: Importing Managed Dependencies > (Comment Added) > > I don't know that confluence was designed for debates so I am posting > this here. > > Mark, while I appreciate your feedback I have to take issue with the -1. > > In all the groups that I work with that use Maven every single one of > the Configuration Management teams that manages the projects requires > that the engineers provide them with a list of all the dependencies and > their versions used in the build and that they be easily able to verify > that. Furthermore, there can never be a possiblity that the version > might change if the build is rerun. In maven 1 we handled that via the > jar override mechanism. With Maven 2 we use dependency management. In > fact, we couldn't even attempt to use Maven 2 until I allowed > dependencyManagement to override transitive dependenciies. This > proposal aims to make working in this kind of environment easier. > > The problem with your alternative (MNG-612) is that no matter how good > your conflict resolver is we can't use it as it doesn't meet the > requirements. With version ranges there is always the chance that a new > version will come along and get picked up if a build is redone. The CM > folks will never allow us to release a product where that possiblity > exists. > > Given that, I could easily say that MNG-612 is a bad idea and I should > vote -1 on it, but I wouldn't do that since I really don't care how the > feature works as I won't be using it. > > So if you don't like dependency management I would suggest you vote -0 > instead as there are many environments where dependency management is > simply required. > > Ralph > > [EMAIL PROTECTED] wrote: >> Comment Added : MAVEN <http://docs.codehaus.org/display/MAVEN> : >> Importing Managed Dependencies >> <http://docs.codehaus.org/display/MAVEN/Importing+Managed+Dependencies> >> : Re: Importing Managed Dependencies >> <http://docs.codehaus.org/display/MAVEN/Importing+Managed+Dependencies?focusedCommentId=20217857#comment-20217857> >> >> >> Importing Managed Dependencies >> <http://docs.codehaus.org/display/MAVEN/Importing+Managed+Dependencies> >> has been commented on by mark >> <http://docs.codehaus.org/display/%7Emark> (Oct 19, 2007). >> >> Comment: >> >> -1: I think opening up distributed dependency management is just going >> to dig ourselves a bigger hole that will very hard to get out of. I >> would like to see the use of dependency management decline in >> preference to using a better conflict resolution strategy (MNG-612), >> ideally in conjunction with version ranges. >> >> Powered by Atlassian Confluence >> <http://www.atlassian.com/wiki/?clicked=footer>, the Enterprise Wiki >> <http://www.atlassian.com/wiki/?clicked=footer>. (Version: 2.5.5 >> Build:#811 Jul 25, 2007) - Bug/feature request >> <http://jira.atlassian.com/secure/BrowseProject.jspa?id=10470> - >> Contact Administrators </administrators.action> >> >> Unsubscribe or edit your notifications preferences >> <http://docs.codehaus.org/users/viewnotifications.action> > > --------------------------------------------------------------------- > 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]
