If anyone actually wants this to happen, you probably need to file a JIRA issue so this can be considered in 2.0.x (or 2.1). William, your idea could perhaps even be implemented in 2.0.x.
Discussions like this, esp on the Users list, generally do not result in new functionality as there are simply too many things to keep track of... Wayne On 5/3/07, William Ferguson <[EMAIL PROTECTED]> wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
