maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Fox <>
Subject Re: [Proposal] EasyVersionMaintenance
Date Wed, 29 Jul 2009 23:27:36 GMT
First question, wouldn't ${project.version} solve the use case of
updating same versioned dependencies?

Also: "A <version> that was omitted in a <dependency> section can only
be resolved if the referenced modules are resolved. So if it is NOT
part of the sub-tree where the build was invoked we have a problem to
solve. However this can be done by adding a list of projects named
"closure" similar to the reactor but that is build from the
toplevel-pom recursively following the <modules>."

This doesn't work unless you have a whole project checked out on disk.
You couldn't resolve from a repository because the module entry refers
to a subfolder of where  to pom is, but in a repository it's it has no complete coordinates.

On Wed, Jul 29, 2009 at 5:46 PM, Joerg Hohwiller<> wrote:
> Hash: SHA1
> Hi Brett,
> Thanks for taking care. I already thought that this will gonna be ignored.
>> So the summary is that if omitted on a dependency, the group ID and
>> version should match that of the current project, and on deployment it
>> needs to be populated?
> Yes, correctly - at least the version is the important one
> for omitting, I have no need for omitting groupId.
> DependencyManagement should still overrule for compatibility
> reasons.
> If it is all just that easy as you point it out ;)
> Thanks
>  Jörg
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla -
> Mx8An3DskYpBA7xhLbzMA3Ohz7NvTipN
> =H6YW
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message