Maven 2 & 3
  1. Maven 2 & 3
  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
          Joe Cool added a comment -

          I hereby kindly ask you to fix the bug.

          I really have problems convincing my colleagues to switch to Maven when such a bug is not fixed for month.

          Show
          Joe Cool added a comment - I hereby kindly ask you to fix the bug. I really have problems convincing my colleagues to switch to Maven when such a bug is not fixed for month.
          Hide
          Steffan added a comment -

          The issue origins seems to be the DefaultModelInheritanceAssembler.class wich automatically adds the parents artifactId no matter what.
          According to the site-plugin in documentation the inheritance of the parents artifactId can enabled by adding a trailing / to the url.
          But the InheritanceModel doesnt apply this rule.

          Details on: http://maven.apache.org/guides/mini/guide-site.html
          Note: the trailing slash in the URL above indicates that any subprojects that inherit this value should append their artifact ID to the path instead of using it as-is.

          My solution, the method assembleDistributionInheritence(...) should be modified like this:

          ...
          if ( childDistMgmt.getSite() == null )
          {
          if ( parentDistMgmt.getSite() != null )
          {
          Site site = new Site();
          childDistMgmt.setSite( site );
          site.setId( parentDistMgmt.getSite().getId() );
          site.setName( parentDistMgmt.getSite().getName() );
          site.setUrl( parentDistMgmt.getSite().getUrl() );
          // modification, add the .endWith("/") to the condition
          if ( site.getUrl() != null && site.getUrl().endsWith( "/" ) )

          { site.setUrl( appendPath( site.getUrl(), child.getArtifactId(), appendPaths ) ); }

          }
          }
          ...

          Show
          Steffan added a comment - The issue origins seems to be the DefaultModelInheritanceAssembler.class wich automatically adds the parents artifactId no matter what. According to the site-plugin in documentation the inheritance of the parents artifactId can enabled by adding a trailing / to the url. But the InheritanceModel doesnt apply this rule. Details on: http://maven.apache.org/guides/mini/guide-site.html Note: the trailing slash in the URL above indicates that any subprojects that inherit this value should append their artifact ID to the path instead of using it as-is. My solution, the method assembleDistributionInheritence(...) should be modified like this: ... if ( childDistMgmt.getSite() == null ) { if ( parentDistMgmt.getSite() != null ) { Site site = new Site(); childDistMgmt.setSite( site ); site.setId( parentDistMgmt.getSite().getId() ); site.setName( parentDistMgmt.getSite().getName() ); site.setUrl( parentDistMgmt.getSite().getUrl() ); // modification, add the .endWith("/") to the condition if ( site.getUrl() != null && site.getUrl().endsWith( "/" ) ) { site.setUrl( appendPath( site.getUrl(), child.getArtifactId(), appendPaths ) ); } } } ...
          Hide
          jameswdumay added a comment -

          Here is a fix for Maven 2.0.8 with tests.

          Show
          jameswdumay added a comment - Here is a fix for Maven 2.0.8 with tests.
          Hide
          Brian Fox added a comment -

          Thanks for the patch. I updated it to handle \ in the path and another small issue I found while testing.

          Show
          Brian Fox added a comment - Thanks for the patch. I updated it to handle \ in the path and another small issue I found while testing.
          Hide
          Brian Fox added a comment -

          This patch breaks existing behavior (the docs are wrong).

          Show
          Brian Fox added a comment - This patch breaks existing behavior (the docs are wrong).
          Hide
          William Ferguson added a comment -

          Brian, we all seem to want this fix, but don't want to break existing behaviour (however bizarre it may be).

          The proper solution seems to be to add a POM attribute/element like either:

          • use-inherited-urls with a default of false
          • append-artifactId-to-parent-urls with a default of true
            But this requires a change to the POM schema which I suspect will be much harder to organise..

          A temporary solution might be to do the same thing using well-documented POM properties, eg

          • mng-3244-use-inherited-urls with a default of false
          • mng-3244-append-artifactId-to-parent-urls with a default of true
            And when (hopefully not if) the POM schema is changed to accomodate the proper solution the implementation can be readily switched from one to the other and even handle fallback and notification of the appropriate configuration.
          Show
          William Ferguson added a comment - Brian, we all seem to want this fix, but don't want to break existing behaviour (however bizarre it may be). The proper solution seems to be to add a POM attribute/element like either: use-inherited-urls with a default of false append-artifactId-to-parent-urls with a default of true But this requires a change to the POM schema which I suspect will be much harder to organise.. A temporary solution might be to do the same thing using well-documented POM properties, eg mng-3244-use-inherited-urls with a default of false mng-3244-append-artifactId-to-parent-urls with a default of true And when (hopefully not if) the POM schema is changed to accomodate the proper solution the implementation can be readily switched from one to the other and even handle fallback and notification of the appropriate configuration.
          Hide
          Benjamin Bentmann added a comment -

          This patch breaks existing behavior (the docs are wrong).

          Well, then you might find this patch useful, intended to save users from confusion and providing some further tweaks to the guide. It's one thing to have a controversal behavior but it's definitively a bad thing to have incorrect documentation.

          Show
          Benjamin Bentmann added a comment - This patch breaks existing behavior (the docs are wrong). Well, then you might find this patch useful, intended to save users from confusion and providing some further tweaks to the guide. It's one thing to have a controversal behavior but it's definitively a bad thing to have incorrect documentation.
          Hide
          Brian Fox added a comment -

          Site patch is applied.

          Show
          Brian Fox added a comment - Site patch is applied.
          Hide
          John Allen added a comment -

          remember that the site distro URL and the project URL are related. If you add the documented but missing feature of being '/' aware for one of them (i.e. as you have with this patch and its handling of site distro url) you will need to add the same feature to the project url assembly.

          We have had to declare explicit project.url and distroManagement.site.url elements in EVERY pom of our multi-module proejcts because we also use real identifying information in these URLS, namely the $

          {project.groupId}

          /$

          {project.artifactId}

          /$

          {project.version}

          Show
          John Allen added a comment - remember that the site distro URL and the project URL are related. If you add the documented but missing feature of being '/' aware for one of them (i.e. as you have with this patch and its handling of site distro url) you will need to add the same feature to the project url assembly. We have had to declare explicit project.url and distroManagement.site.url elements in EVERY pom of our multi-module proejcts because we also use real identifying information in these URLS, namely the $ {project.groupId} /$ {project.artifactId} /$ {project.version}
          Hide
          John Allen added a comment - - edited

          After playing with some patch some more i came across another problem beyond the one mentioned above. You need to ensure that the trailing slash is propagated to the child projects URLs (distroManagement.site.url and project.url) otherwise the logic based upon the presence of the trailing slash stop working. i.e. if you call appendPaths you must ensure that the resulting path ends with a '/'.

          Show
          John Allen added a comment - - edited After playing with some patch some more i came across another problem beyond the one mentioned above. You need to ensure that the trailing slash is propagated to the child projects URLs (distroManagement.site.url and project.url) otherwise the logic based upon the presence of the trailing slash stop working. i.e. if you call appendPaths you must ensure that the resulting path ends with a '/'.
          Hide
          Stefan Seidel added a comment -

          Will this also be implemented for the SCM URLs and the various other places where the artifactid is automatically appended? Because this bug here supercedes MNG-2290, which supercedes MNG-2219, which is about SCM URLs. And can someone, please, document that? Because a guide is not a place to put such an important piece of information. Maybe the right place would be the docs for the pom.xml structure?

          Show
          Stefan Seidel added a comment - Will this also be implemented for the SCM URLs and the various other places where the artifactid is automatically appended? Because this bug here supercedes MNG-2290 , which supercedes MNG-2219 , which is about SCM URLs. And can someone, please, document that? Because a guide is not a place to put such an important piece of information. Maybe the right place would be the docs for the pom.xml structure?
          Hide
          Jens Riboe added a comment -

          [I sent this comment to the list, without any repsonse, so I decided to put them here - where they belong]

          As I understand it; the current rule implements implicit URLs as
          $

          {parent.url}

          /$

          {project.artifactId}

          For example:
          <scm>
          <connection>${parentPOM.scm.connection}/${project.artifactId}

          </connection>
          ...
          /scm>
          Where parentPOM is a made-up symbol denoting an upward search for the pom property that follows (scm.connection).

          So, how about the following suggestion:
          The Super POM contains this kind of definition for all URLs where this rule applies today. When the effective POM
          is computed for a sub-project it uses the "closest" url definition that contains the symbol parentPOM. If none is
          found expect the def in super pom, this one is used and the rule applies as it always has.

          On the other hand, if one decides to put an url expression containing parentPOM into a POM of type 'pom',
          then there is a new definition and will be used. That means, we have a way to define how sub-project urls should
          be constructed. I would be delighted if I could define an expression like
          $

          {parentPOM.scm.connection}

          /$

          {project.name}

          /trunk

          There is a residual problem, however: I cannot define both an url expansion expression and an actual url expression
          that is intended to be used in sub-projects. The easiest solution, is just to have two organization poms, the top-most
          pom contains the url expansion expressions (overriding the rule from the super pom) and the one beneath is the
          original org pom, containing actual urls that will be used in the expansions further down.

          I'm convinced there are other more elegant solutions. However, the suggestion above would be fairly easy to implement
          without breaking existing code and poms (or require a POM version increment), but still provide a way for org-pom
          designers to tweak the url expansions the way they want.

          Comments / Objections ???

          Show
          Jens Riboe added a comment - [I sent this comment to the list, without any repsonse, so I decided to put them here - where they belong] As I understand it; the current rule implements implicit URLs as $ {parent.url} /$ {project.artifactId} For example: <scm> <connection>${parentPOM.scm.connection}/${project.artifactId} </connection> ... /scm> Where parentPOM is a made-up symbol denoting an upward search for the pom property that follows (scm.connection). So, how about the following suggestion: The Super POM contains this kind of definition for all URLs where this rule applies today. When the effective POM is computed for a sub-project it uses the "closest" url definition that contains the symbol parentPOM. If none is found expect the def in super pom, this one is used and the rule applies as it always has. On the other hand, if one decides to put an url expression containing parentPOM into a POM of type 'pom', then there is a new definition and will be used. That means, we have a way to define how sub-project urls should be constructed. I would be delighted if I could define an expression like $ {parentPOM.scm.connection} /$ {project.name} /trunk There is a residual problem, however: I cannot define both an url expansion expression and an actual url expression that is intended to be used in sub-projects. The easiest solution, is just to have two organization poms, the top-most pom contains the url expansion expressions (overriding the rule from the super pom) and the one beneath is the original org pom, containing actual urls that will be used in the expansions further down. I'm convinced there are other more elegant solutions. However, the suggestion above would be fairly easy to implement without breaking existing code and poms (or require a POM version increment), but still provide a way for org-pom designers to tweak the url expansions the way they want. Comments / Objections ???
          Hide
          Brian Fox added a comment -

          There isn't a way that i know of to refer to a value in the parent pom. This would require defining a whole new property and is more than I think we want to do in 2.0.x.

          Show
          Brian Fox added a comment - There isn't a way that i know of to refer to a value in the parent pom. This would require defining a whole new property and is more than I think we want to do in 2.0.x.
          Show
          Brian Fox added a comment - Note, dission on dev list: http://www.nabble.com/Comments---Ideas-for-MNG-3244-td15808822s177.html#a15808822
          Hide
          Brian Fox added a comment -

          There seems to be no solution available to fix this in 2.0.x

          Show
          Brian Fox added a comment - There seems to be no solution available to fix this in 2.0.x
          Hide
          Kenneth Flynn added a comment -

          I'm fairly new to Maven, but I find the default behavior for all URLs very confusing. I understand the desired behavior, but many projects are just not arranged like the default behavior implies. The same URL alteration happens for SCM urls, the overall project URL, etc. I had initially created a corporate parent POM that I had hoped could work about 85% of our SVN repos by default, but I will have to override every one in the actual POM for each project (the suggested workaround).

          I would strongly argue for a change to the POM to be able to turn this off globally (not just for site URLs). I'd prefer for that to be the default (I think the current behavior violates the principle of least surprise), but that's water under the bridge in terms of compatibility at this point. We really need a way of turning this off though--I really think it will lead to simpler POMs.

          Show
          Kenneth Flynn added a comment - I'm fairly new to Maven, but I find the default behavior for all URLs very confusing. I understand the desired behavior, but many projects are just not arranged like the default behavior implies. The same URL alteration happens for SCM urls, the overall project URL, etc. I had initially created a corporate parent POM that I had hoped could work about 85% of our SVN repos by default, but I will have to override every one in the actual POM for each project (the suggested workaround). I would strongly argue for a change to the POM to be able to turn this off globally (not just for site URLs). I'd prefer for that to be the default (I think the current behavior violates the principle of least surprise), but that's water under the bridge in terms of compatibility at this point. We really need a way of turning this off though--I really think it will lead to simpler POMs.
          Hide
          Steven MountJoy added a comment -

          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

          Show
          Steven MountJoy added a comment - 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
          Hide
          Steven MountJoy added a comment -

          patch by Steven MountJoy

          Show
          Steven MountJoy added a comment - patch by Steven MountJoy
          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:
              Brian Fox
              Reporter:
              Jacob Robertson
            • Votes:
              43 Vote for this issue
              Watchers:
              40 Start watching this issue

              Dates

              • Created:
                Updated: