svn.relative.location

[Ian Young]

We have a convention in our parent POMs that project POMs define a property called svn.relative.location.  The places where this is used in the V2 and V3 parent POMs insert this value in different ways, e.g.:

(v2) <url>http://svn.shibboleth.net/view/${svn.relative.location}</url>

(v3) <url>http://svn.shibboleth.net/view${svn.relative.location}</url>

That implies that a v2 project should have a svn.relative.location of the general form "reponame" or "reponame/module" while a v2 project should have one in the form "/reponame" or "/reponame/module".

Most of the projects I've looked at do what their associated parent POM implicitly expects, but some do not.  The V3 IdP parent POM does not do what the V3 parent POM expects, for example.  The result is this effective POM:

  <scm>
    <connection>scm:svn:https://svn.shibboleth.netjava-identity-provider/idp-attribute-api</connection>
    <developerConnection>scm:svn:https://svn.shibboleth.netjava-identity-provider/idp-attribute-api</developerConnection>
    <url>http://svn.shibboleth.net/viewjava-identity-provider/idp-attribute-api</url>
  </scm>

Same applies to the opensaml V3 parent POM.  I was able to find at least one component (java-support) which does use the V3 "/reponame" convention, though, so it's not the case that everything is either one way or the other.

I'm assuming that the fact that this has apparently not caused any problems is a sign that this part of the parent POMs isn't being used, so obviously one option would be just to strike the whole relative location thing.  I'm guessing there was a reason for it, though, so let's assume we don't want to do that.

Another way of fixing things would be leave the parent POMs different and fix the individual projects which are doing the "wrong" thing.  That would probably be pretty easy, but it would mean that we'd have to remember to noodle with the svn.relative.location if something moved from the V2 parent to the V3 parent.  That doesn't sound desirable to me.

What I'd actually propose is that we pick one or other convention and apply it to both parent POMs and all projects inheriting them.  Given the preponderance of modules using the "reponame" convention, I suggest that we pick that. We'd need to change the V3 parent POM (which in the <scm> area would now be identical to the V2 parent POM) and the java-support POM, and maybe some more individual projects; we'd have to look, though.

No, I didn't start my day thinking this was what I'd be looking at.

Comments?

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/dev/attachments/20130227/cdb22b26/attachment.bin