You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by EJ Ciramella <ej...@upromise.com> on 2007/05/01 21:11:06 UTC
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.
Re: dependency management problems...
Posted by Wayne Fay <wa...@gmail.com>.
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 <Wi...@yarris.com> 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:waynefay@gmail.com]
> 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 <Wi...@yarris.com> 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:waynefay@gmail.com]
> > 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 <ej...@upromise.com> 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:ejciramella@upromise.com]
> > > 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: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: dependency management problems...
Posted by William Ferguson <Wi...@yarris.com>.
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:waynefay@gmail.com]
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 <Wi...@yarris.com> 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:waynefay@gmail.com]
> 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 <ej...@upromise.com> 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:ejciramella@upromise.com]
> > 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: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: dependency management problems...
Posted by Wayne Fay <wa...@gmail.com>.
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 <Wi...@yarris.com> 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:waynefay@gmail.com]
> 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 <ej...@upromise.com> 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:ejciramella@upromise.com]
> > 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: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: dependency management problems...
Posted by William Ferguson <Wi...@yarris.com>.
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:waynefay@gmail.com]
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 <ej...@upromise.com> 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:ejciramella@upromise.com]
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: dependency management problems...
Posted by Wayne Fay <wa...@gmail.com>.
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 <ej...@upromise.com> 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:ejciramella@upromise.com]
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: dependency management problems...
Posted by EJ Ciramella <ej...@upromise.com>.
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:ejciramella@upromise.com]
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org