Maven
  1. Maven
  2. MNG-5000

[regression] child distributionManagment.site.url not correct in a flat directory layout when child's artifactId doesn't match its module name

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0.2
    • Fix Version/s: 3.0.3
    • Component/s: None
    • Labels:
      None
    • Environment:
      windows
    • Complexity:
      Intermediate
    • Testcase included:
      yes
    • Number of attachments :
      1

      Description

      There is a multimodule flat project structure:
      root
      module1
      module2

      module1 has an artifactID of 'module1' (same as directory name)
      modulu2 has an artifactID of 'module-2' (different to directory name)

      After a 'mvn site-deploy' the generated report has the folder structure:
      /root
      /root/module-2
      /module1

      So based on the artifactID the submodules are created as a child of the root - or not.
      This is at least inconsistent and should be changed to be handled always the same - independent of the artifactID.

      This is also important for other plugins (i.e. the dashboard plugin).
      They seem to have some hardcoded directory structure (preferring submodules as childs of the root report).
      Due to this bug (see http://jira.codehaus.org/browse/MOJO-1630) the links between reports there still don't work as long as artifactID=module's directory.

      Attached you will find a testcase (based on maven3, but can also be used with maven2 when the version of the site-plugin is changed).

        Issue Links

          Activity

          Hide
          Benjamin Bentmann added a comment -

          You're right about this being a core issue, I missed to recognize the discrepancy in the module-2 project, fixed in r1072613.

          The cause of the issue was that module-2 has a different artifactId than its module name. Let me stress that such a layout is a recipe for trouble as it results in effective URLs that depend on the source of the POM (project vs repo), i.e. if somebody (e.g. a plugin) was to construct the POM of this project from the repository, it would see different URLs than those used when building the project. The same problem would also arise during local project building when URLs are inherited from a grand-parent via one or more intermediate parents and any of those parents is resolved from the repo. For this reason, it's highly recommended to synchronize the module name with the artifactId.

          Show
          Benjamin Bentmann added a comment - You're right about this being a core issue, I missed to recognize the discrepancy in the module-2 project, fixed in r1072613 . The cause of the issue was that module-2 has a different artifactId than its module name. Let me stress that such a layout is a recipe for trouble as it results in effective URLs that depend on the source of the POM (project vs repo), i.e. if somebody (e.g. a plugin) was to construct the POM of this project from the repository, it would see different URLs than those used when building the project. The same problem would also arise during local project building when URLs are inherited from a grand-parent via one or more intermediate parents and any of those parents is resolved from the repo. For this reason, it's highly recommended to synchronize the module name with the artifactId.
          Hide
          Lukas Theussl added a comment -

          such a layout is a recipe for trouble as it results in effective URLs that depend on the source of the POM (project vs repo)

          If this is true then there must be something wrong with Maven...

          it would see different URLs than those used when building the project

          I don't understand why this should be the case, are there any docs or examples you could point me to? The state of a pom should be uniquely specified by its maven coordinates and those of its parent, not by the module structure of the build. In other words, why shouldn't it be possible to move a module into a different directory, without changing the module's identity?

          Show
          Lukas Theussl added a comment - such a layout is a recipe for trouble as it results in effective URLs that depend on the source of the POM (project vs repo) If this is true then there must be something wrong with Maven... it would see different URLs than those used when building the project I don't understand why this should be the case, are there any docs or examples you could point me to? The state of a pom should be uniquely specified by its maven coordinates and those of its parent, not by the module structure of the build. In other words, why shouldn't it be possible to move a module into a different directory, without changing the module's identity?
          Hide
          Benjamin Bentmann added a comment -

          I don't understand why this should be the case, are there any docs or examples you could point me to?

          http://svn.apache.org/repos/asf/maven/maven-2/tags/maven-2.2.1/maven-project/src/main/java/org/apache/maven/project/MavenProject.java, getModulePathAdjustment() starts with two nice FIXME comments that outline the design flaw.

          The state of a pom should be uniquely specified by its maven coordinates and those of its parent, not by the module structure of the build

          Yes this would be the ideal but the bug raised here demands to consider the directory name in the local project structure which is lost once the POMs got installed/deployed to a repo. When I investigated the bug, I was originally tempted to close it as won't fix because of the irreproducibility it drags in but then again, this entire URL inheritance/adjustment feature is broken itself so I stopped bothering and just restored the status quo as in 2.x.

          Show
          Benjamin Bentmann added a comment - I don't understand why this should be the case, are there any docs or examples you could point me to? http://svn.apache.org/repos/asf/maven/maven-2/tags/maven-2.2.1/maven-project/src/main/java/org/apache/maven/project/MavenProject.java , getModulePathAdjustment() starts with two nice FIXME comments that outline the design flaw. The state of a pom should be uniquely specified by its maven coordinates and those of its parent, not by the module structure of the build Yes this would be the ideal but the bug raised here demands to consider the directory name in the local project structure which is lost once the POMs got installed/deployed to a repo. When I investigated the bug, I was originally tempted to close it as won't fix because of the irreproducibility it drags in but then again, this entire URL inheritance/adjustment feature is broken itself so I stopped bothering and just restored the status quo as in 2.x.
          Hide
          Lukas Theussl added a comment -

          I'm still confused about this... Benjamin: what's the actual algorithm to calculate the effective url if it gets inherited? The current site docs say:

          If subprojects inherit the site URL from a parent POM, they will automatically append their <artifactId> to form their effective deployment location.
          

          This is what I always had in mind but it is obviously not correct for the attached test project (the modules get deployed into the same directory as root, instead of having their artifactId appended). At least the behavior is consistent now AFAIS so I guess the docs need to be adjusted.

          Show
          Lukas Theussl added a comment - I'm still confused about this... Benjamin: what's the actual algorithm to calculate the effective url if it gets inherited? The current site docs say: If subprojects inherit the site URL from a parent POM, they will automatically append their <artifactId> to form their effective deployment location. This is what I always had in mind but it is obviously not correct for the attached test project (the modules get deployed into the same directory as root, instead of having their artifactId appended). At least the behavior is consistent now AFAIS so I guess the docs need to be adjusted.
          Hide
          Benjamin Bentmann added a comment -

          I already mentioned getModulePathAdjustment().

          Show
          Benjamin Bentmann added a comment - I already mentioned getModulePathAdjustment() .

            People

            • Assignee:
              Benjamin Bentmann
              Reporter:
              Stefan Hansel
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: