svn.relative.location

[Brent Putman]

On 2/27/13 9:33 PM, Tom Zeller wrote:
> What do you think about renaming "java-identity-provider" to
> "shib-identity-provider" ... would that make it better ? I am not
> proposing this real seriously, just chatting. 

You mean to in turn facilitate its use as <name>?  No, not really, I
mean if you look at how <name> gets used in a Maven sense, it really
think it should be human readable and descriptive.

If you mean just in general the notion of renaming the actual repo in
svn:  I don't have strong feelings, but if we were going to do that I
think we'd want to be consistent.  Right now the consistent thing is all
the Java projects begin with java-, etc, vs Scott's stuff with cpp- and
so on.  If we want to change the whole thing, I guess maybe, but then
what for example would we call java-opensaml or
java-metadata-aggregator?  Probably not shib-opensaml.  Can't be just
opensaml b/c that is ambiguous wrt the C++ library. 

I don't personally see a big reason to change the repo names, though. 
What's in a name, anyway? :-)


> I think we agree on dropping svn.relative.location.

I certainly agree that I don't want to spend a lot of time worrying
about it. :-)


>
> So we would move the <scm> block to the appropriate project level,
> e.g. idp-parent or java-support ?


Hadn't given it much thought yet.

I think there's really (at least) 2 issues here:

1) For what use, and how, we want to make use of the <scm> section for
our own purposes (i.e. just project metadata). 

2) Whether we want to try and make the SCM part of site generation
work.  In case the thread isn't accessible to someone who cares, I'll
reproduce below what I said about this part.  I don't really know if we
can make that work period, since it seems to want to assume/insist that
the artifactId is part of the end of the URL.  I didn't find anything
when I looked.

If we want to abandon #2, then I think whatever we want to do for #1 is
fine, although I do think that something that minimizes copying the
<scm> section to multiple POM's is probably best.  Perhaps something
that looks close to what we have now, but that obviously fixes the "/"
inconsistency (I couldn't validate what Chad told me about that having
some kind of special behavior).  Maybe just have svn.relative.location
(or whatever we call it) set to the repo name in which that
project/module appears.




SCM Report issue:

> For completely different reasons, the SCM output of v2 and v3 reports
> is broken.  The SCM report plugin seems to default to appending
> ${project.artifactId } on the end of the various SCM URL's.  I don't
> immediately see any way to change that.  You can change the name of
> the directory that it puts in the check-out command after the URL, but
> that doesn't affect how the URL is constructed[1].
>
>
> So we get output that looks like this for a monolithic project (where
> the artifactId = "xmltooling"):
>
> http://svn.shibboleth.net/view/java-xmltooling/xmltooling
>
> $ svn checkout https://svn.shibboleth.net/java-xmltooling/xmltooling
> xmltooling
>
>
> and this for a multi-module project (where the artifactId =
> "aggregator-cli")
>
> http://svn.shibboleth.net/view/java-metadata-aggregator/aggregator-cli
>
> $ svn checkout
> https://svn.shibboleth.net/java-metadata-aggregator/aggregator-cli
> aggregator-cli
>
>
> which are invalid b/c the artifactId isn't really a part of any of
> those paths and/or it doesn't take into account that there's actually
> a trunk/tags/branches structure underneath there.