On Thu, Jul 30, 2009 at 9:51 AM, Ralph Goers<ralph.go...@dslextreme.com> wrote: > > 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.
Yes both in Jiras and on this list. In 2.2.x John took out that part of the code because it introduced too many problems that had no obvious solutions. > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
