I was actually thinking that the "validate" phase would only compile a list of dependencies up to the furthermost lifecycle phase required by the list of goals specified. But I guess it amounts to the same thing.
William -----Original Message----- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Friday, 4 May 2007 2:00 AM To: Maven Users List Subject: Re: dependency management problems... So essentially you'd break up and move the monolithic "validate" phase into a series of "mini-validates" that fire immediately before every other lifecycle phase, to validate the artifacts necessary for (only) that phase are available. I think it would complicate things a bit, but it doesn't sound unreasonable. Wayne On 5/2/07, William Ferguson <[EMAIL PROTECTED]> wrote: > Interesting point. > > Aren't dependencies just compile time dependencies? So there is no > need to resolve them unless your build includes the compile:compile goal. > > Plugin dependencies are only resolved if that plugin is required as > part of the current build. > So why do the (compile) dependencies need to be resolved if > compilation is not part of the build? > > William > > > -----Original Message----- > From: Wayne Fay [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 2 May 2007 1:24 PM > To: Maven Users List > Subject: Re: dependency management problems... > > As far as I know, you can't. Maven resolves all dependencies etc at > the beginning of the lifecycle, so it can find all transitive > artifacts etc and make sure EVERYTHING is available in the local cache > before proceeding with the build. > > Wayne > > On 5/1/07, EJ Ciramella <[EMAIL PROTECTED]> wrote: > > Here's another way of phrasing this question - if a module has a > > dependency on another one, how do you stop it from attempting to > > download until absolutely necessary (say at compile time, NOT at > > process-resources time)? > > > > -----Original Message----- > > From: EJ Ciramella [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, May 01, 2007 3:11 PM > > To: Maven Users List > > Subject: dependency management problems... > > > > We're having problems building modules like this from scratch. If > > we run process resources from the top most level, submodule.B > > complains about not being able to find module1's artifacts (why > > would submodule.B need module 1's jar artifact just to process resources?). > > > > parent - version 1.0-SNAPSHOT > > | > > |------->module1 - version 1.0-SNAPSHOT > > | > > |------->module2 - version 1.0-SNAPSHOT > > |----------->submodule.A- version 1.0-SNAPSHOT > > |----------->submodule.B- version 1.0-SNAPSHOT > > > > > > > > I'm really at the end of my rope on this one. The only way to > > successfully get this to go through is to run a mvn install from the > > top most level first. What's crazy is submodule.A has the same > > dependency and goes through just fine. > > > > -------------------------------------------------------------------- > > - 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] > > --------------------------------------------------------------------- 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]
