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]
