Re: POM inheritance behaving unexpectedly
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:
…
1.0.6
http://svn/${artifactId}/${nextReleaseVersion}
${nextReleaseVersion}-SNAPSHOT
scm:svn:${svnUrl}
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
RE: POM inheritance behaving unexpectedly
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).
>>
>> - 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
And where does the parent POM came from?
> ... 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.
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.
> 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.
An email address and a nick name :)
- Jörg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: POM inheritance behaving unexpectedly
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
RE: POM inheritance behaving unexpectedly
Tommy Knowlton wrote on Tuesday, February 06, 2007 11:19 PM:
> Hello,
>
> I've got a parent POM that declares e.g.,
>
>
> ...
> http://javabuild2.mycompany.com/${project.artifactId}
>
>
> (in other words, top-level configuration that varies by the project
> that has declared this parent).
>
> Problem is, when I look at the effective POM (mvn
> help:effective-pom), it shows up as follows:
>
>
> ...
> m-installer
> http://javabuild2.mycompany.com/m-installer/m-installer
>
>
> See where the duplication is occurring? Should I expect that? How can
> I use top-level config in the parent pom that uses values taken from
> the "child" pom?
>
> Note that the problem doesn't only occur when I use
> help:effective-pom, that's just been a useful way to help me figure
> out wth is going on. Also, it's not just but other values that
> are referred using a ${project.XYZ} form. On the other hand, inside
> the "child" POM, I have other values that refer to ${artifactId} (not
> ${project.artifactId}) and these behave as I would expect.
>
> 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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
