Well, darn. I finally read the proposal. From what I can tell this
is largely what I implemented in https://svn.apache.org/repos/asf/maven/components/branches/maven-2.1.x-MNG-624/
. However I was never able to finish that because I ran into one
small little problem.
The proposal says the "resolved" pom will be written to $
{project.build.directory}/pom-transformed.xml. That is correct.
However, when resolving a child it will want to look at this pom since
the version of the parent will be in it but may not be in the
"unresolved" pom.xml. Here is the problem. When resolving the child
pom the value of ${project.build.directory} isn't known. If the
variable is defined in the root pom for the project all the parent
poms have to be traversed until the definition is found or the
superpom is encountered. I really didn't want to do that but couldn't
think of any clever way around the problem. Other than that the code
on that branch does everything that is being suggested. However, it is
no severely out of date.
I did not implement the delayed handling of artifacts without
versions, primarily because I am led to believe that 3.0 will do a
much better job of this by using graphs.
Ralph
On Jul 29, 2009, at 4:33 PM, Brett Porter wrote:
I think I skimmed over the modules bit. As my comment suggested, I
only thought it was to replace them where they matched.
ie:
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>other-artifactId</artifactId>
<version>${project.version}</version>
</dependency>
would become:
<dependency>
<artifactId>other-artifactId</artifactId>
</dependency>
Which I think we've seen suggested before.
Anything more than that is probably not going to be as feasible and
prone to confusion.
On 29/07/2009, at 7:27 PM, Brian Fox wrote:
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<jo...@j-
hohwiller.de> 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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
