On Jul 30, 2009, at 5:03 AM, Brian Fox wrote:
We also have to be careful of the problems introduced in 2.1.0 because
of transforming the pom...gpg can't sign etc.
Are those itemized anywhere? Eventually these problems need to be
solved.
Ralph
2009/7/29 Ralph Goers <ralph.go...@dslextreme.com>:
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
---------------------------------------------------------------------
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
