Maven
  1. Maven
  2. MNG-3244

inherited site url not properly handling parameters

    Details

    • Number of attachments :
      3

      Description

      Here is the test case to reproduce 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.

      1. fix-inherited-site-url.patch
        3 kB
        jameswdumay
      2. guide-site.patch
        4 kB
        Benjamin Bentmann
      3. mng-3244_patch.txt
        16 kB
        Steven MountJoy

        Issue Links

          Activity

          Hide
          Niall Gallagher added a comment - - edited

          My company has a flat SVN structure, with trunk/, tags/ and branches/ folders in every project. e.g.

          .../corporate-pom/trunk/
          .......................pom.xml
          ................./tags/
          ................./branches/

          .../project1/trunk/
          ..................pom.xml
          ............/tags/
          ............/branches/

          We were hoping to factor out scm, site and nexus urls from all of our projects into a corporate pom. Due to this bug though, maven is appending artifactid again after trunk/ in inherited urls, which doesn't make sense for this structure. So basically this bug will prevent us from factoring out most of the configuration, and we'll have to copy/paste the same url template into every pom.

          Can we consider fixing this bug for maven 2.x again?

          ..Edited to remove a suggestion which has some problems on closer examination.

          Show
          Niall Gallagher added a comment - - edited My company has a flat SVN structure, with trunk/, tags/ and branches/ folders in every project. e.g. .../corporate-pom/trunk/ .......................pom.xml ................./tags/ ................./branches/ .../project1/trunk/ ..................pom.xml ............/tags/ ............/branches/ We were hoping to factor out scm, site and nexus urls from all of our projects into a corporate pom. Due to this bug though, maven is appending artifactid again after trunk/ in inherited urls, which doesn't make sense for this structure. So basically this bug will prevent us from factoring out most of the configuration, and we'll have to copy/paste the same url template into every pom. Can we consider fixing this bug for maven 2.x again? ..Edited to remove a suggestion which has some problems on closer examination.
          Hide
          Niall Gallagher added a comment -

          @Steven MountJoy- I looked at that patch, and I think it would improve the situation for some people, but for us it's not going to fix the broken handling of our scm urls because we put our variables in the middle of the urls unfortunately, and we put "/trunk" at the end.

          @all
          Perhaps looking for patterns in urls is not the way to go to decide whether or not to apply the fixed logic.

          How about we apply the fix if property "mng-3244-append-artifactId-to-parent-urls" is set to "false" (as William Ferguson above suggested 2.5 years ago), otherwise we apply existing behaviour?

          I can't see any way that this could break existing behaviour.

          Show
          Niall Gallagher added a comment - @Steven MountJoy- I looked at that patch, and I think it would improve the situation for some people, but for us it's not going to fix the broken handling of our scm urls because we put our variables in the middle of the urls unfortunately, and we put "/trunk" at the end. @all Perhaps looking for patterns in urls is not the way to go to decide whether or not to apply the fixed logic. How about we apply the fix if property "mng-3244-append-artifactId-to-parent-urls" is set to "false" (as William Ferguson above suggested 2.5 years ago), otherwise we apply existing behaviour? I can't see any way that this could break existing behaviour.
          Hide
          Benny Goemans added a comment -

          Since I've experiencing issues on this as well, I've been thinking that referencing i.e. project.version in a parent pom (to the parent's version) should be possible.
          I might not see a certain UC or already implemented behaviour, but wouldn't this be possible (and still be backwards compatible) by adding one of two behaviours:

          1. A way to specify properties that are resolved to the correct version (from the pom that they're in) either at install time or at the time the effective pom is generated. A proposal on this option would be to use i.e. #

          {property}

          or maybe $[property]
          I think that this might even be possible in a Maven plugin, but there will be a problem with backing up the pom first then as well. If there's a way to hook into the effective pom generation it can be done cleanly though without touching the pom on disk.

          2. A way to specify a certain parent in the hierarchy, though this would require a model change. It would then be possible to request a certain parent, i.e. by doing $

          {project.parent.someParentGroup.someParentId}

          Personally I like #1 the most, though #2 is probably the most powerful. Both will of course require a substantial amount of work, but I expect that #2 will require a lot more than #1.

          ps. just wondering: are votes counted together from all related issues? If so I might vote on them all

          Show
          Benny Goemans added a comment - Since I've experiencing issues on this as well, I've been thinking that referencing i.e. project.version in a parent pom (to the parent's version) should be possible. I might not see a certain UC or already implemented behaviour, but wouldn't this be possible (and still be backwards compatible) by adding one of two behaviours: 1. A way to specify properties that are resolved to the correct version (from the pom that they're in) either at install time or at the time the effective pom is generated. A proposal on this option would be to use i.e. # {property} or maybe $ [property] I think that this might even be possible in a Maven plugin, but there will be a problem with backing up the pom first then as well. If there's a way to hook into the effective pom generation it can be done cleanly though without touching the pom on disk. 2. A way to specify a certain parent in the hierarchy, though this would require a model change. It would then be possible to request a certain parent, i.e. by doing $ {project.parent.someParentGroup.someParentId} Personally I like #1 the most, though #2 is probably the most powerful. Both will of course require a substantial amount of work, but I expect that #2 will require a lot more than #1. ps. just wondering: are votes counted together from all related issues? If so I might vote on them all
          Hide
          Falko Modler added a comment - - edited

          It's sad to see that this issue hasn't been fixed in all these years. People really need it.

          I ended up specifying following snippet in each and every child pom:

          <distributionManagement>
            <!-- repositories inherited-->
            <site>
              <id>${distributionManagement.site.id}</id>
              <url>${distributionManagement.site.url}</url>
            </site>
          </distributionManagement>
          

          Whereas the same snippet is defined in the parent pom (including repositories of course!) and this parent pom also defines the referenced properties:

          <distributionManagement.site.id>someid</distributionManagement.site.id>
          <distributionManagement.site.url>scp://somehost.example.org/u/admin/maven/site/${project.artifactId}</distributionManagement.site.url>
          

          I needed to do the same for project.url and all the URLs in project.scm.

          It's a quite cumbersome workaround but this way I can use a "dumb" copy and paste approach when creating new child poms - without needing to remember to append the artifactIds! At the the same time I can just release the parent pom as usual, including correct site deployment.

          Show
          Falko Modler added a comment - - edited It's sad to see that this issue hasn't been fixed in all these years. People really need it. I ended up specifying following snippet in each and every child pom: <distributionManagement> <!-- repositories inherited--> <site> <id> ${distributionManagement.site.id} </id> <url> ${distributionManagement.site.url} </url> </site> </distributionManagement> Whereas the same snippet is defined in the parent pom (including repositories of course!) and this parent pom also defines the referenced properties: <distributionManagement.site.id> someid </distributionManagement.site.id> <distributionManagement.site.url> scp://somehost.example.org/u/admin/maven/site/${project.artifactId} </distributionManagement.site.url> I needed to do the same for project.url and all the URLs in project.scm. It's a quite cumbersome workaround but this way I can use a "dumb" copy and paste approach when creating new child poms - without needing to remember to append the artifactIds! At the the same time I can just release the parent pom as usual, including correct site deployment.
          Hide
          Dmitry Katsubo added a comment -

          I have jumped to this issue from MSITE-334, as I have the same issue with automatic appending of artifactId to inherited site URL, which does not work well with custom "templated" URLs.
          In our environment we use URL like this:

          dav:http://host/nexus/content/sites/maven-site/${project.groupId}/${project.artifactId}/${project.version}/
          
          Show
          Dmitry Katsubo added a comment - I have jumped to this issue from MSITE-334 , as I have the same issue with automatic appending of artifactId to inherited site URL, which does not work well with custom "templated" URLs. In our environment we use URL like this: dav:http: //host/nexus/content/sites/maven-site/${project.groupId}/${project.artifactId}/${project.version}/

            People

            • Assignee:
              brianfox brianfox
              Reporter:
              Jacob Robertson
            • Votes:
              45 Vote for this issue
              Watchers:
              42 Start watching this issue

              Dates

              • Created:
                Updated: