Issues with SCM strings

[Mykel Alvis <my...@weirdness.com>]

I'm copying and forwarding from another message to see if I can get a
response on this.

I have a parent pom that defines the SCM of itself and all it's children by
using
scm:svn:http://${scm.host}/svnrepos/${object.namespace}/${artifactId}/trunk

and when I do help:effective-pom,  I end up with
scm:svn:http://${scm.host}/svnrepos/${object.namespace
}/${artifactId}/trunk/${artifactId}

Having read another post regarding this, I'm curious if anyone knows the
actual update that I've acquired that makes this error occur.
What do I need to revert to in order to eliminate this problem?




-- 
I'm just an unfrozen caveman software developer.  I don't understand your
strange, "modern" ways.

Re: Issues with SCM strings

[Mykel Alvis <my...@weirdness.com>]

After a bit more googling and reading some other peoples' comments, I
realized that this is apparently "as designed".  Which leads me to the
question of ...why would you ever want that?

I can understand that, in a multi-module build, the submodules are probably
one level under the parent.  In our environments, however, every component
at its lowest level of granularity, is its own project, with its own
trunk/tags/branches trees.  This way, we can use svn externals to join
everything up again and make it all look like a multi-module build with a
pom to aggregate the modules.  Given the default behavior of silently
appending artifactId to the end of the svn string (and with no known way to
stop it), I'm forced to duplicate the <scm> tags in every child pom.

I read on another post that something to do with this is on the radar for
some eventual 2.1 release, but am I the only person who's having this much
trouble with this appended artifactId?

As a caveat, I've never before been in the position to dictate the structure
of the source repository until now.  Before, every project had to be
identified by its own scm string because they rarely, if ever, followed a
pattern.  But now I want to take advantage of the inheritence mechanism for
parent poms in order to force children to conform to a particular format.
Alas, the scm plugin doesn't allow me to do this, and further confounds me
by not documenting that this occurs (or if the documentation exists, it's
very effectively hidden)


On 1/11/07, Mykel Alvis <my...@weirdness.com> wrote:
>
> I'm copying and forwarding from another message to see if I can get a
> response on this.
>
> I have a parent pom that defines the SCM of itself and all it's children
> by using
> scm:svn:http://${scm.host}/svnrepos/${object.namespace
> }/${artifactId}/trunk
>
> and when I do help:effective-pom,  I end up with
> scm:svn:http://${scm.host}/svnrepos/${object.namespace
> }/${artifactId}/trunk/${artifactId}
>
> Having read another post regarding this, I'm curious if anyone knows the
> actual update that I've acquired that makes this error occur.
> What do I need to revert to in order to eliminate this problem?
>
>
>
>
> --
> I'm just an unfrozen caveman software developer.  I don't understand your
> strange, "modern" ways.




-- 
I'm just an unfrozen caveman software developer.  I don't understand your
strange, "modern" ways.