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). - Jörg
Thanks for the reply, Jörg. I noticed that you are the reporter on that issue. Since I don't (yet?) have a codehaus JIRA login, I wonder whether you'll mind adding the following comment to that issue:
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 … because we don't have the "normal" trunk/tags/branches subversion layout, but instead we keep anticipated or previously released version numbers as part of each module's repo layout. But, I a) don't want to check out all of the different source branches, and b) I don't want to have the extra level of "clutter" in my local workspace, and c) when I work on a different release branch, it's just a 'svn switch' to point at the other version's source repo. Aside from the fact that I'm off the well-trodden path as regards svn repo layout, I think my point remains valid that the helpful expansion mechanism can't make the indicated assumption. 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. Thanks, -- Tommy
