We also have to be careful of the problems introduced in 2.1.0 because of transforming the pom...gpg can't sign etc.
2009/7/29 Ralph Goers <[email protected]>: > 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<[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] >>> >> >> >> --------------------------------------------------------------------- >> 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]
