Maven Shared Components
  1. Maven Shared Components
  2. MSHARED-18

Inheritance of elements from site descriptor quite broken

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: maven-doxia-tools-1.0
    • Component/s: maven-doxia-tools
    • Labels:
      None
    • Environment:
      Maven 2.0.8, JDK 1.5.0_12, WinXP

      Description

      After updating to 2.0-beta-6, I never get proper site output for multi module projects. I attached a simple dummy project that shall help to reproduce the problem.

      When I perform a reactor build of the site (i.e. "project-parent> mvn site"), the pages of the sub module project-module-1 properly inherit most of the decorator elements, except for the custom "overview" menu. That is, the site of the sub module contains the menu configured for the parent project despite the sub module specifying its own menu.-

      In contrast, when I only build the site of the sub module (i.e. "project-module-1> mvn site"), many decoration elements are not inherited from the parent's site.xml like <version>, <bannerRight>, <skin>, <links>. However, now the sub module's site properly outputs its own menu items (i.e. "Module-Item" instead of "Parent-Item" for the attached projects).

      This issues might be a duplicate/relative of MSITE-256 but as I cannot safely judge from its description, I opened a new issue.

      1. bug2.zip
        6 kB
        Anne Gerodolle
      2. exception.txt
        3 kB
        Anne Gerodolle
      3. bug1.zip
        6 kB
        Anne Gerodolle
      4. site-directory.patch
        8 kB
        Benjamin Bentmann
      5. site-directory.patch
        4 kB
        Benjamin Bentmann
      6. project.zip
        5 kB
        Benjamin Bentmann

        Issue Links

          Activity

          Hide
          Anne Gerodolle added a comment -

          "Looks like you ran into MSITE-180."
          it may be related however symptoms are not the same: it's not that "IF none of the poms (module or parent) don't have an url tag,
          THEN site inheritence quitely isn't applied, for example in the parent's site.xml".
          what I observe is : the child's site is not built at all if the url tag is missing. and an exception is raised (exception.txt).

          a difficulty for reporting these issues correctly is that behaviour of inheritance seems quite instable. Sometimes, menus are not inherited, sometimes, only menus from parents are shown. Sometimes, skins are not inherited, or partially, sometimes they are...

          In the example bug2.zip, with the site plugin checked out from trunk and rebuilt yesterday,if I run "mvn site" in the parent's folders, menu "menu1" is not inherited.

          And I'm sorry for the numerous small posts of yesterday : I tried to add a comment to each uploaded file, but clearly it does not work like that !

          Show
          Anne Gerodolle added a comment - "Looks like you ran into MSITE-180 ." it may be related however symptoms are not the same: it's not that "IF none of the poms (module or parent) don't have an url tag, THEN site inheritence quitely isn't applied, for example in the parent's site.xml". what I observe is : the child's site is not built at all if the url tag is missing. and an exception is raised (exception.txt). a difficulty for reporting these issues correctly is that behaviour of inheritance seems quite instable. Sometimes, menus are not inherited, sometimes, only menus from parents are shown. Sometimes, skins are not inherited, or partially, sometimes they are... In the example bug2.zip, with the site plugin checked out from trunk and rebuilt yesterday,if I run "mvn site" in the parent's folders, menu "menu1" is not inherited. And I'm sorry for the numerous small posts of yesterday : I tried to add a comment to each uploaded file, but clearly it does not work like that !
          Hide
          Benjamin Bentmann added a comment -

          Moreover, if I do not specify some "<url>" tag in the parent pom.xml, I now observe an exception I did not obtain before.

          Looks like you ran into MSITE-180.

          Show
          Benjamin Bentmann added a comment - Moreover, if I do not specify some "<url>" tag in the parent pom.xml, I now observe an exception I did not obtain before. Looks like you ran into MSITE-180 .
          Hide
          Anne Gerodolle added a comment -

          modules sites are built but a menu that should be inherited is not

          Show
          Anne Gerodolle added a comment - modules sites are built but a menu that should be inherited is not
          Hide
          Anne Gerodolle added a comment -

          exceptionraised when trying to build the site (bug1.zip)

          Show
          Anne Gerodolle added a comment - exceptionraised when trying to build the site (bug1.zip)
          Hide
          Anne Gerodolle added a comment -

          with current version of maven-site-plugin rebuilt from svn trunk, module site is not built when typing mvn clean then mvn site

          Show
          Anne Gerodolle added a comment - with current version of maven-site-plugin rebuilt from svn trunk, module site is not built when typing mvn clean then mvn site
          Hide
          Anne Gerodolle added a comment -

          Hi,

          I've dowloaded the current version of the maven-site-plugin from the svn trunk.

          I still observe the problem that menus are not inherited from the parent.

          Moreover, if I do not specify some "<url>" tag in the parent pom.xml, I now observe an exception I did not obtain before. I am enclosing 3 files :
          exception.txt shows the new exception raised when no url tag is defined
          bug1.zip : the project without url tag defined (modules sites are not built if typing mvn clean then mvn site)
          bug2.zip : url tag define (modules sites are built but "menu1" is not inherited by modules)

          Show
          Anne Gerodolle added a comment - Hi, I've dowloaded the current version of the maven-site-plugin from the svn trunk. I still observe the problem that menus are not inherited from the parent. Moreover, if I do not specify some "<url>" tag in the parent pom.xml, I now observe an exception I did not obtain before. I am enclosing 3 files : exception.txt shows the new exception raised when no url tag is defined bug1.zip : the project without url tag defined (modules sites are not built if typing mvn clean then mvn site) bug2.zip : url tag define (modules sites are built but "menu1" is not inherited by modules)
          Hide
          Siveton Vincent added a comment -

          new patch applied and updated code in site-plugin

          Show
          Siveton Vincent added a comment - new patch applied and updated code in site-plugin
          Hide
          Benjamin Bentmann added a comment -

          Fixing this against maven-doxia-tools is not that easy because the only chance I see is an API redesign.

          Unlike my first approach for the maven-site-plugin, I chose to change the siteDirectory parameter for the doxia-tools methods to be a string denoting the relative path to the site directory, eg. "src/site", instead of passing around the base directory of the original project from which the siteDirectory mojo parameter was taken. Callers of the doxia-tools like the maven-site-plugin should be able to easily create this string from their (absolute) java.io.File-based mojo parameter via SiteTool.getRelativePath( siteDirectory.getAbsolutePath(), basedir.getAbsolutePath() ). Doing this once in the plugin for the current project and not for each ancestor project is the key to fix the issue.

          Of course, a relative path could be encoded via java.io.File as well but I see the risk that people errorneously pass in absolute paths that they got from Maven's path translation.

          BTW, JUnit assertions are written in the order (expected, actual).

          Show
          Benjamin Bentmann added a comment - Fixing this against maven-doxia-tools is not that easy because the only chance I see is an API redesign. Unlike my first approach for the maven-site-plugin, I chose to change the siteDirectory parameter for the doxia-tools methods to be a string denoting the relative path to the site directory, eg. "src/site", instead of passing around the base directory of the original project from which the siteDirectory mojo parameter was taken. Callers of the doxia-tools like the maven-site-plugin should be able to easily create this string from their (absolute) java.io.File-based mojo parameter via SiteTool.getRelativePath( siteDirectory.getAbsolutePath(), basedir.getAbsolutePath() ) . Doing this once in the plugin for the current project and not for each ancestor project is the key to fix the issue. Of course, a relative path could be encoded via java.io.File as well but I see the risk that people errorneously pass in absolute paths that they got from Maven's path translation. BTW, JUnit assertions are written in the order (expected, actual).
          Hide
          Benjamin Bentmann added a comment -

          Here is a fix.

          Show
          Benjamin Bentmann added a comment - Here is a fix.
          Hide
          Benjamin Bentmann added a comment -

          The fix for MSITE-91 in r473599 was the cause for this issue, more precisely the following lines from getSiteDescriptorFile():

          String relativePath = getRelativePath( siteDirectory.getAbsolutePath(), basedir.getAbsolutePath() );
          File siteDescriptor = new File( relativePath, "site_" + locale.getLanguage() + ".xml" );
          

          The METHOD parameter "basedir" may refer to an ancestor project while the MOJO parameter siteDirectory always refers to the currently executed sub project. And just to bring in another directory, the final path siteDescriptor is setup using a relative path which gets resolved against the user's current working directory which might be anything (though usually the root of a reactor build).

          Show
          Benjamin Bentmann added a comment - The fix for MSITE-91 in r473599 was the cause for this issue, more precisely the following lines from getSiteDescriptorFile(): String relativePath = getRelativePath( siteDirectory.getAbsolutePath(), basedir.getAbsolutePath() ); File siteDescriptor = new File( relativePath, "site_" + locale.getLanguage() + ".xml" ); The METHOD parameter "basedir" may refer to an ancestor project while the MOJO parameter siteDirectory always refers to the currently executed sub project. And just to bring in another directory, the final path siteDescriptor is setup using a relative path which gets resolved against the user's current working directory which might be anything (though usually the root of a reactor build).

            People

            • Assignee:
              Siveton Vincent
              Reporter:
              Benjamin Bentmann
            • Votes:
              2 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development