[jira] Commented: (MNG-3244) inherited site url not properly handling parameters

["Steven MountJoy (JIRA)" <ji...@codehaus.org>]

    [ http://jira.codehaus.org/browse/MNG-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207763#action_207763 ] 

Steven MountJoy commented on MNG-3244:
--------------------------------------

I'm going to summarize all that this peculiar functionality touches upon, some of which can be traced in the issue links above, in order to justify my attached patch and hope for its consensus adoption.

There's a Maven 1-ey method in DefaultModelInheritanceAssembler, appendPath(..), that may append a child path relative to a parent (project) path and this path becomes the returned URL. In practice, this method is called upon from three places in this inheritance-assembling class: all of <scm>, the <url> inside <site> inside <distributionManagement>, and the top-level <url>, where the parent has a value and the child doesn't. And in each case, the child path is its <artifactId>. The boolean param that determines whether to "append child to parent," AFAICT, is hard-coded to true in each of these cases and, hence, no matter what the inherited value may be, the child path (artifactId) is appended and for most inheritance schemes, you see a strange reflective..artifact..of the artifactId tacked on the end of these resolved URLs. Again, it all sounds very Maven 1-ey, where children are logically inside parent or relative to it.

Most inheritance schemes, as I've said, for these values are of this flavor: the inherited child value is http://www.foo.com/etc/${project.artifactId} -- according to my following the bug trails. Rather than rewrite this aspect of the model, as Brett Porter suggested [1], my proposed patch quietly inserts a check for a certain condition and, if present, follows different inheritance logic. My aims were:

1. Non-disruptive insertion - if present, do this, else keep the status quo.
2. Cover 90% (or better) of the cases - there may be other fringe (inheritance) cases my patch does not address but I think I've landed on the majority and, with #1 in mind, it does no worse for those cases.

So my patch is basically this: if the child has no value and the parent does (for those POM elements mentioned), and if the parent value ends with a Maven expression (i.e. ${blah}), then child value = parent value, otherwise, as you were. (Paul Harrison suggested [2] the choice of the algorithm be the presence of '/' at the end of the parent value but I think the "ends with Maven expression" is a more direct approach.)

My patch includes new units and has been utilized in a full rebuild of 2.2.2-RC1-SNAPSHOT successfully. I look forward to hearing everyone's feedback.

- Steven

[1] http://jira.codehaus.org/browse/MNG-4508?focusedCommentId=204629&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_204629

[2] http://jira.codehaus.org/browse/MNG-4508?focusedCommentId=174940&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_174940




> inherited site url not properly handling parameters
> ---------------------------------------------------
>
>                 Key: MNG-3244
>                 URL: http://jira.codehaus.org/browse/MNG-3244
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Inheritance and Interpolation, Sites & Reporting
>    Affects Versions: 2.0.7
>            Reporter: Jacob Robertson
>            Assignee: Brian Fox
>             Fix For: 3.x (to be reviewed)
>
>         Attachments: fix-inherited-site-url.patch, guide-site.patch, mng-3244_patch.txt
>
>
> Here is the test case to reroduce this problem.  Take the following two pom.xml files
> <?xml version="1.0" encoding="UTF-8"?>
> <project>
> 	<groupId>org.bar</groupId>
> 	<artifactId>foo</artifactId>
> 	<name>foo</name>
> 	<version>1.0-SNAPSHOT</version>
> 	<packaging>pom</packaging>
> 	<modelVersion>4.0.0</modelVersion>
> 	<distributionManagement>
> 		<site>
> 			<id>foo-site</id>
> 			<url>file://C:/Documents and Settings/foo/.m2/site/${project.artifactId}</url>
> 		</site>
> 	</distributionManagement>
> </project>
> <?xml version="1.0" encoding="UTF-8"?>
> <project>
> 	<groupId>org.bar</groupId>
> 	<artifactId>baz</artifactId>
> 	<name>baz</name>
> 	<version>1.0-SNAPSHOT</version>
> 	<packaging>pom</packaging>
> 	<modelVersion>4.0.0</modelVersion>
> 	<parent>
> 		<artifactId>foo</artifactId>
> 		<groupId>org.bar</groupId>
> 		<version>1.0-SNAPSHOT</version>
> 	</parent>
> </project>
> And run the site-deploy goal on each.  What you get under the site directory is this
> - site
> /- foo
> ---/site docs
> /- baz
> ---/- baz (extra directory)
> --- ---/site docs
> This is the simplest test case.  In the case where I have a "grandparent" pom, the site directory uses the grandparent/parent as the path to the site, and doesn't use the actual artifactId of the artifact I'm creating the site for.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira