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 meaningless...ie it has no complete coordinates. On Wed, Jul 29, 2009 at 5:46 PM, Joerg Hohwiller<[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > 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 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkpwwx0ACgkQmPuec2Dcv/8khQCdEMSSc/JrXVNfwMTGbEfOASHe > Mx8An3DskYpBA7xhLbzMA3Ohz7NvTipN > =H6YW > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > 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]
