On 2/7/07, Jörg Schaible <[EMAIL PROTECTED]> wrote:
Hi Tommy,Tommy Knowlton wrote on Thursday, February 08, 2007 3:30 AM: > On 2/7/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: >> Tommy Knowlton wrote on Tuesday, February 06, 2007 11:19 PM: >> >>> Is this a bug in the code that resolves ${project} references? >> >> No, this is a feature (that fails miserably when the > directory in your repository does not match the artifactId > ... MNG-2290). >> > >> All of this could have been avoided, if the expanded part is not the >> artifactId, but the basename of the current directory. Especially >> for the scm elements, this is IMHO the only valid assumption. > > Hmm, I would dispute that this is a valid assumption (that the SCM > repo URL is derivable from the basename of the current directory). > > Suffice it to say that SCM's that I've used allow you to checkout from > a repository URL to a (differently-named) local workspace. This fact > alone makes the above-mentioned assumption false. > > E.g., > > svn co http://svn.mycorp.com/X/Y/Z ./some-name-other-than-Z > > or, more concretely, just today I did: > > svn co http://svn/modules/honeycomb/1.0.0 ./honeycomb And where does the parent POM came from? > ... because we don't have the "normal" trunk/tags/branches subversion > layout, This is a different situation. In this case you can *never* inherit the SCM entries and each of your POMs must have its own SCM section anyway. M2 cannot guess those entries. The issue is valid if you inherit from the parent POM one directory level above. If your parent is received from the repo, the SCM URL is always completely different.
The "child" POM: <project> … <properties> <nextReleaseVersion>1.0.6</nextReleaseVersion> <svnUrl>http://svn/${artifactId}/${nextReleaseVersion}</svnUrl> </properties <version>${nextReleaseVersion}-SNAPSHOT</version> <scm> <connection>scm:svn:${svnUrl}</connection> <!-- Since the above connection value does not vary from one child project to the next ("Don't Repeat Yourself"), I had decided to put this into the parent. But in the parent, I said: <connection>scm:svn:${pom.svnUrl}</connection> … and the effective pom was "not as expected," coming with an extra ${artifactId} suffix. --> </scm> </project> IMO, the root of the evil is the "helpful" addition of ${artifactId} to a value THAT I'VE SPECIFIED in the parent POM. Opinionated software is fine, and go ahead to make guesses about what I meant to say whenever I say nothing, but when I explicitly make a declaration, LEAVE IT ALONE should be the rule. Of course, the emphasis above should not be taken for shouting at you, Jörg, simply emphasis for the benefit of all who will read this. I think it's very important that we as a community "get this." When a declaration of intent is made, the software should not try to out-guess that, nor add to that, nor take away.
> If you're not comfortable adding the comment on my behalf, I'll look > into what it takes to get a JIRA login at codehaus. An email address and a nick name :)
Cool, I (mistakenly) guessed that a JIRA login would require me to be "sponsored" by a "committer" or some other such hoops… I'll add the comments to the issue sometime after I get in to the office this morning. Thanks again. -- Tommy
