Maven
  1. Maven
  2. MNG-4508

No way to avoid adding artifactId to site urls

    Details

    • Complexity:
      Intermediate
    • Number of attachments :
      0

      Description

      Currently, whenever a child pom inherits from a parent (and doesn't override the relevant settings), both project.url and project.distributionManagement.site.url have the name of the child artifact appended.

      It would be nice to be able to have something like

      :code:
      <url>scpexe://host/blah/$

      {project.artifactId}

      /$

      {project.version}

      </url>
      :code:

      and have this inherited to all child poms in the obvious way.

      My usecase for this is that we have a single parent pom for all our projects, with useful settings such as distributionManagement, and I'd like to be able to deploy their sites to a single directory and have Apache generate me a directory listing for all the child projects. However, I curently have no way of releasing the parent project without obliterating the list of child projects.

        Issue Links

          Activity

          Carlos Sanchez made changes -
          Field Original Value New Value
          Issue Type Bug [ 1 ] Improvement [ 4 ]
          Priority Major [ 3 ] Minor [ 4 ]
          Jason van Zyl made changes -
          Fix Version/s Reviewed [ 13555 ]
          Hide
          Kenney Westerhof added a comment -

          Place to fix: maven-project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java

          perhaps check wheter the parentpath already contains an expression for artifactId, or maybe add a decision
          whether to append based on the path ending in a slash or not.

          Show
          Kenney Westerhof added a comment - Place to fix: maven-project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java perhaps check wheter the parentpath already contains an expression for artifactId, or maybe add a decision whether to append based on the path ending in a slash or not.
          Kenney Westerhof made changes -
          Fix Version/s 2.1-alpha-1 [ 13143 ]
          Fix Version/s Reviewed Pending Version Assignment [ 13555 ]
          Eric Turcotte made changes -
          Link This issue is related to MNG-3075 [ MNG-3075 ]
          Jason van Zyl made changes -
          Fix Version/s 2.1.x [ 13142 ]
          Fix Version/s 2.1-alpha-1 [ 13143 ]
          Hide
          Cyril ADRIAN added a comment - - edited

          Hello,

          I have the same problem with scm URLs which have the artifactId appended too. That's extremely disturbing because we don't want to nest projects with an scm repository (FWIW it's svn).

          We prefer a flat structure even if we have parent-child dependancies. And of course, we don't want to duplicate the <scm> section in each and every POM (which we currently have to do).

          I think the priority of this bug should be more important.

          Is there a way we can help with the issue?

          Thanks

          Show
          Cyril ADRIAN added a comment - - edited Hello, I have the same problem with scm URLs which have the artifactId appended too. That's extremely disturbing because we don't want to nest projects with an scm repository (FWIW it's svn). We prefer a flat structure even if we have parent-child dependancies. And of course, we don't want to duplicate the <scm> section in each and every POM (which we currently have to do). I think the priority of this bug should be more important. Is there a way we can help with the issue? Thanks
          Hide
          Richard van der Hoff added a comment -

          We actually found a workaround for this problem in our particular usecase.

          The main distributionManagement section in our parent-pom has the url ready to be appended to by child poms, and the parent-pom also has a profile which overrides it just for that one pom; thus:

            <profiles>
              <profile>
                <id>deploying-base-pom-itself</id>
                <activation>
                  <file>
                    <exists>THIS-IS-base-pom</exists>
                  </file>
                </activation>
                <distributionManagement>
                  <site>
                    <id>mx-release</id>
                    <url>scpexe://host/blah/base-pom</url>
                  </site>
                </distributionManagement>
              </profile>
            </profiles>
          

          This profile is then enabled for the base pom by creating a file entitled THIS-IS-base-pom.

          I think this might also work for the scm url.

          Obviously this becomes a less useful solution for deeper project heirarchies, but it works pretty well for us.

          Show
          Richard van der Hoff added a comment - We actually found a workaround for this problem in our particular usecase. The main distributionManagement section in our parent-pom has the url ready to be appended to by child poms, and the parent-pom also has a profile which overrides it just for that one pom; thus: <profiles> <profile> <id> deploying-base-pom-itself </id> <activation> <file> <exists> THIS-IS-base-pom </exists> </file> </activation> <distributionManagement> <site> <id> mx-release </id> <url> scpexe://host/blah/base-pom </url> </site> </distributionManagement> </profile> </profiles> This profile is then enabled for the base pom by creating a file entitled THIS-IS-base-pom. I think this might also work for the scm url. Obviously this becomes a less useful solution for deeper project heirarchies, but it works pretty well for us.
          Hide
          Cyril ADRIAN added a comment - - edited

          Good idea, thanks

          Although I still need a proper fix because we usually have two levels:

          • our "enterprise" pom
          • an "application head" containing all the modules an dinheritting from the "enterprise" pom
          • the application modules inheritting from the "application head"

          Anyway, thanks for the idea. Maybe I can refine it to use our two levels (if the names of the flag files are well defined it may be simple enough to put everything in the "enterprise" pom).

          UPDATE: it does not work... I cannot put an <scm> within a <profile>

          Show
          Cyril ADRIAN added a comment - - edited Good idea, thanks Although I still need a proper fix because we usually have two levels: our "enterprise" pom an "application head" containing all the modules an dinheritting from the "enterprise" pom the application modules inheritting from the "application head" Anyway, thanks for the idea. Maybe I can refine it to use our two levels (if the names of the flag files are well defined it may be simple enough to put everything in the "enterprise" pom). UPDATE: it does not work... I cannot put an <scm> within a <profile>
          Jason van Zyl made changes -
          Fix Version/s 3.x [ 13145 ]
          Fix Version/s 3.0 [ 13142 ]
          Hide
          Paul Harrison added a comment -

          I would like to add a plea for this behaviour to be modified - we too have a similar 3 level pom inheritance hierarchy, and it is irritating to have to specify the URLs in the final level when the root is specified in the top level because the intermedate level is automactically inserted. I think that the problems come about here because there is not a clear distinction made between pom inhertance and project aggregation - typically if a project only inherits from another project then the values should only be inherited, without modification - it a project is an aggregated child as well, then various URLs can have artifactIds automatically added to the end.

          Even with this modification to behaviour I would also support the suggestion above that automatic appending of artifactId only occurs when the URL ends explictly with a "/" - this allows for more complex URL layouts to be specified in the root POM with the use of variables such as the

          <url>scpexe://host/blah/$

          {project.artifactId}

          /$

          {project.version}

          </url>

          which I think is a rather commonly desired layout.

          Show
          Paul Harrison added a comment - I would like to add a plea for this behaviour to be modified - we too have a similar 3 level pom inheritance hierarchy, and it is irritating to have to specify the URLs in the final level when the root is specified in the top level because the intermedate level is automactically inserted. I think that the problems come about here because there is not a clear distinction made between pom inhertance and project aggregation - typically if a project only inherits from another project then the values should only be inherited, without modification - it a project is an aggregated child as well, then various URLs can have artifactIds automatically added to the end. Even with this modification to behaviour I would also support the suggestion above that automatic appending of artifactId only occurs when the URL ends explictly with a "/" - this allows for more complex URL layouts to be specified in the root POM with the use of variables such as the <url>scpexe://host/blah/$ {project.artifactId} /$ {project.version} </url> which I think is a rather commonly desired layout.
          Paul Harrison made changes -
          Link This issue is depended upon by MNG-3244 [ MNG-3244 ]
          Paul Harrison made changes -
          Link This issue is depended upon by MNG-3244 [ MNG-3244 ]
          Paul Harrison made changes -
          Link This issue relates to MNG-3244 [ MNG-3244 ]
          Jason van Zyl made changes -
          Component/s Sites & Reporting [ 12030 ]
          Affects Version/s 2.0.5 [ 12294 ]
          Key MNG-2915 MSITE-449
          Fix Version/s 3.x [ 13145 ]
          Complexity Intermediate
          Project Maven 2 & 3 [ 10500 ] Maven 2.x Site Plugin [ 11146 ]
          Hide
          Dennis Lundberg added a comment -

          Is this really an issue for the Site Plugin? The comments seem to indicate that it has to do with how maven-model works (or doesn't work) with properties.

          Show
          Dennis Lundberg added a comment - Is this really an issue for the Site Plugin? The comments seem to indicate that it has to do with how maven-model works (or doesn't work) with properties.
          Brett Porter made changes -
          Project Maven 2.x Site Plugin [ 11146 ] Maven 2 & 3 [ 10500 ]
          Complexity Intermediate
          Key MSITE-449 MNG-4508
          Hide
          Brett Porter added a comment -

          correct. This requires a model change - probably by a combination of two things:

          1. the facility for the site and reporting plugins to intelligently create a multi-module site map with equivalent functionality to the current URL extension
          2. removal of the inheritance rules (or site elements) from the POM in a new model version

          We can keep this issue to the latter

          Show
          Brett Porter added a comment - correct. This requires a model change - probably by a combination of two things: the facility for the site and reporting plugins to intelligently create a multi-module site map with equivalent functionality to the current URL extension removal of the inheritance rules (or site elements) from the POM in a new model version We can keep this issue to the latter
          Brett Porter made changes -
          Fix Version/s 3.1.alpha1 [ 16093 ]
          Brett Porter made changes -
          Link This issue is related to MNG-4506 [ MNG-4506 ]
          Brett Porter made changes -
          Fix Version/s 3.1 [ 15565 ]
          Fix Version/s 3.1.alpha1 [ 16093 ]
          Benjamin Bentmann made changes -
          Link This issue is duplicated by MNG-2872 [ MNG-2872 ]
          Benjamin Bentmann made changes -
          Component/s Inheritance and Interpolation [ 11570 ]
          Benjamin Bentmann made changes -
          Link This issue is duplicated by MNG-4878 [ MNG-4878 ]
          Hannes Kogler made changes -
          Link This issue relates to MRELEASE-331 [ MRELEASE-331 ]
          Hide
          Hannes Kogler added a comment -

          It seems that the problem described here is responsible for my current problem when trying to use the maven-release-plugin ...
          I linked the following issue: MRELEASE-331

          Show
          Hannes Kogler added a comment - It seems that the problem described here is responsible for my current problem when trying to use the maven-release-plugin ... I linked the following issue: MRELEASE-331
          Hide
          Darryl L. Miles added a comment -

          Remove the inheritance rules but provide a maven configured variable $

          {maven.project.path}

          or something that will becomes "/parent-parent/parent" in deepest level of a 3 level project. The super POM will be an empty string. The mid-level will be "/parent-parent". Now users get the best of both worlds without being chained to the convention.

          Show
          Darryl L. Miles added a comment - Remove the inheritance rules but provide a maven configured variable $ {maven.project.path} or something that will becomes "/parent-parent/parent" in deepest level of a 3 level project. The super POM will be an empty string. The mid-level will be "/parent-parent". Now users get the best of both worlds without being chained to the convention.
          Stephen Connolly made changes -
          Fix Version/s 3.2 [ 15565 ]
          Fix Version/s Issues to be reviewed for 4.x [ 19871 ]
          Michael Osipov made changes -
          Link This issue is related to MPIR-312 [ MPIR-312 ]

            People

            • Assignee:
              Unassigned
              Reporter:
              Richard van der Hoff
            • Votes:
              25 Vote for this issue
              Watchers:
              26 Start watching this issue

              Dates

              • Created:
                Updated: