Maven Site Plugin
  1. Maven Site Plugin
  2. MSITE-54

In parent site, automatically create link to modules sites and vice-versa

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      6

      Description

      Say we have the following project structure :

      A
      +-- B
      +-- C
      +-- D

      It would be nice to have the following links in the left menu of the generated sites :

      A :
      Modules : B, D

      B :
      Parent : A
      Modules : C

      C :
      Parent : B

      D :
      Parent : A

      1. MNG-661.diff
        28 kB
        Vincent Siveton
      2. MNG-661.diff
        20 kB
        Vincent Siveton
      3. SiteMojoPatch.txt
        9 kB
        John Allen
      4. SiteMojoPatch.txt
        10 kB
        John Allen
      5. SiteMojoPatch.txt
        10 kB
        John Allen

        Issue Links

          Activity

          Brett Porter made changes -
          Field Original Value New Value
          Fix Version/s 2.0-beta-1 [ 11040 ]
          Brett Porter made changes -
          Link This issue is related to MNG-384 [ MNG-384 ]
          Vincent Siveton made changes -
          Assignee Vincent Siveton [ siveton ]
          Hide
          Vincent Siveton added a comment -

          Added these requirements

          Show
          Vincent Siveton added a comment - Added these requirements
          Vincent Siveton made changes -
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Closed [ 6 ]
          Hide
          Brett Porter added a comment -

          had to stop the copying due to a bug

          Show
          Brett Porter added a comment - had to stop the copying due to a bug
          Brett Porter made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Vincent Massol made changes -
          Workflow jira [ 36407 ] Maven [ 37005 ]
          Brett Porter made changes -
          Fix Version/s 2.0-beta-1 [ 11040 ]
          Fix Version/s 2.0-beta-2 [ 11861 ]
          Brett Porter made changes -
          Component/s maven-plugins [ 11380 ]
          Component/s maven-site-plugin [ 11802 ]
          Brett Porter made changes -
          Fix Version/s 2.0-beta-2 [ 11861 ]
          Fix Version/s 2.0-beta-3 [ 11991 ]
          Hide
          John Allen added a comment -

          Patch reinstates modules support through use of reactor projects and the parsing of their distributionManagement site information.

          Show
          John Allen added a comment - Patch reinstates modules support through use of reactor projects and the parsing of their distributionManagement site information.
          John Allen made changes -
          Attachment SiteMojoPatch.txt [ 17479 ]
          Hide
          John Allen added a comment -

          My bad, missed bug for leaf nodes that resulted in empty modules menu. New patch has one line difference to previous patch, namely line 791 (in patched file) which changes from:-

          if ( ( addModules && reactorProjects.size() > 1 )

          to:-

          if ( ( addModules && reactorProjects.size() > 1 && project.getModules().size() > 0 ) )

          Show
          John Allen added a comment - My bad, missed bug for leaf nodes that resulted in empty modules menu. New patch has one line difference to previous patch, namely line 791 (in patched file) which changes from:- if ( ( addModules && reactorProjects.size() > 1 ) to:- if ( ( addModules && reactorProjects.size() > 1 && project.getModules().size() > 0 ) )
          John Allen made changes -
          Attachment SiteMojoPatch.txt [ 17483 ]
          Hide
          John Allen added a comment -

          Sigh. i got the whole distributionManagement::site::URL thing about face, taking the distro site details to reflect the projects site's URL location. This is abviously wrong what with it being the wagon setup for deploying the site, not the projects publiclly addressible location which is simply provided by project::Url. So its got a lot simpler, patch now just uses project::Urls to build back and fwd refs. Sorry for the cockups.

          Show
          John Allen added a comment - Sigh. i got the whole distributionManagement::site::URL thing about face, taking the distro site details to reflect the projects site's URL location. This is abviously wrong what with it being the wagon setup for deploying the site, not the projects publiclly addressible location which is simply provided by project::Url. So its got a lot simpler, patch now just uses project::Urls to build back and fwd refs. Sorry for the cockups.
          John Allen made changes -
          Attachment SiteMojoPatch.txt [ 17497 ]
          Hide
          Vincent Siveton added a comment -

          John, thanks a lot for your work!

          Just one comment that I would want to clarify:
          It appears that the last patch creates as well parent project links and module links.
          But, the code uses project.getParent().getUrl() to find the path (if I don't miss something). So, we need to deploy on a web server all projects (before testing for instance).
          IMHO, I think it could be best to copy all generated sites (I mean modules site) in the parent site. Thus, we could browse the site in off line mode.
          WDYT?

          Show
          Vincent Siveton added a comment - John, thanks a lot for your work! Just one comment that I would want to clarify: It appears that the last patch creates as well parent project links and module links. But, the code uses project.getParent().getUrl() to find the path (if I don't miss something). So, we need to deploy on a web server all projects (before testing for instance). IMHO, I think it could be best to copy all generated sites (I mean modules site) in the parent site. Thus, we could browse the site in off line mode. WDYT?
          Hide
          John Allen added a comment -

          Vincent, youre right regarding the limitations of using the projects 'published' URL location for building backward and fwd refs, namely that they only work until the site(s) are deployed but I felt constrained to comply by the maven project model for what defines a projects 'home' and how it relates to its partent, child modules and its distribution management details.

          My observations:-

          • A project can (and therefore someone will) define its project URL to something that is not necessarily derived from its parent. I.e the hierarchical model which we tend to assume is not the only mode of operation in regards to where a site will live in repsect to its parent and modules. This is a key observation.
          • A project's parent is not necessarily defined in the directory above it. A parent project can come from anywhere.

          Therefore one can not rely upon realtive backward and fwd refs: the relationship of a project to their parent and modules in regards to URLs is not necessarily hierarchical and we can not therefore just make the links relative, ie. parent is not just be ../index.html and its modules is not just be ./module_name/index.html.

          But the requirement you quite rightly identify is that we want to 'stage' the site somwhere so it can be tested and reviewed, before real publication but those project links just wont work unless the URLs properly resolves and those are defined for production deployment.

          So how do we handle the preparation of test deployment of a site?

          Dont know ...

          At first I thought we could perform some kind of 'okay so youre running in test deployment mode to i will re-write all URLS such that I expect a parents to be above me and a module to be beneath me and i know everything is going to be based of the same root URL (ie. a file store root) but not even that works becuase although I may be a project 4 deep in a module structure I can have a parent that is in some completely unrelated location.

          So if you want a staged site deployment we will need a new project attribute that lets us discover a project's location in the staged environment, which we would expect to hold a more hierarchical layout to enable deployment to a local filesystem or test HTTP server for easy testing. Note this is basically just saying have another project::URL attribute but that we expect the developer to set it to something more useful and relatively structured so that it can be employed in stage testing.

          Details (please excuse the structure of this!)

          directory: /dirA artifact: projectA, parent: null, url: http://foo, stageUrl: file:///stagingLoc/, site: scp://foo
          directory /dirA/dirB artifact: projectB, parent: projectA, url:http://foo/projectB, stageUrl: [inherited], site: [inherited]
          directory /dirA/dirC artifact: projectC, parent: projectA, url: http://bar/projectC, stageUrl: [inherited], site: scp://bar/projectC
          directory /dirA/dirD artifact: projectD, parent: projectE, url: http://bar/projectD, stageUrl: [inherited], site: scp://bar/projectD
          directory /dirE artifact: projectE, parent: null, url: http://foo/projectE, stageUrl: [file:///stagingLoc/, site: scp://foo/projectE

          gets site:deployed to

          host: foo, directory: /
          host: foo, directory: /projectB
          host: bar, directory: /projectC
          host: bar, directory: /projectD
          host: foo, directory: /projectE

          gets site:staged to:-

          stagingLoc/projectA
          stagingLoc/projectA/projectB
          stagingLoc/projectA/projectC
          stagingLoc/projectA/projectD
          stagingLoc/projectE

          The generation of parent and module links for the stage mode will just use the project::stageURL. the links for deployment mode will use the project::URL. And i guess the new site:stage Mojo will rewrite the links to be stageURL links and then invoke the stage wagon location - we'll need a new site wagon setting as the distributionManagement::site and the project::URL are bound together in their meaning so if we create a new stageURL we well require a new distributionManagement::stageSite setting (which would be set to file::/someLoc in most cases).

          Phew! What a lot of words for something so simple!

          WDYT? Do you see the problem we have?

          Show
          John Allen added a comment - Vincent, youre right regarding the limitations of using the projects 'published' URL location for building backward and fwd refs, namely that they only work until the site(s) are deployed but I felt constrained to comply by the maven project model for what defines a projects 'home' and how it relates to its partent, child modules and its distribution management details. My observations:- A project can (and therefore someone will) define its project URL to something that is not necessarily derived from its parent. I.e the hierarchical model which we tend to assume is not the only mode of operation in regards to where a site will live in repsect to its parent and modules. This is a key observation. A project's parent is not necessarily defined in the directory above it. A parent project can come from anywhere. Therefore one can not rely upon realtive backward and fwd refs: the relationship of a project to their parent and modules in regards to URLs is not necessarily hierarchical and we can not therefore just make the links relative, ie. parent is not just be ../index.html and its modules is not just be ./module_name/index.html. But the requirement you quite rightly identify is that we want to 'stage' the site somwhere so it can be tested and reviewed, before real publication but those project links just wont work unless the URLs properly resolves and those are defined for production deployment. So how do we handle the preparation of test deployment of a site? Dont know ... At first I thought we could perform some kind of 'okay so youre running in test deployment mode to i will re-write all URLS such that I expect a parents to be above me and a module to be beneath me and i know everything is going to be based of the same root URL (ie. a file store root) but not even that works becuase although I may be a project 4 deep in a module structure I can have a parent that is in some completely unrelated location. So if you want a staged site deployment we will need a new project attribute that lets us discover a project's location in the staged environment, which we would expect to hold a more hierarchical layout to enable deployment to a local filesystem or test HTTP server for easy testing. Note this is basically just saying have another project::URL attribute but that we expect the developer to set it to something more useful and relatively structured so that it can be employed in stage testing. Details (please excuse the structure of this!) directory: /dirA artifact: projectA, parent: null, url: http://foo , stageUrl: file:///stagingLoc/ , site: scp://foo directory /dirA/dirB artifact: projectB, parent: projectA, url: http://foo/projectB , stageUrl: [inherited] , site: [inherited] directory /dirA/dirC artifact: projectC, parent: projectA, url: http://bar/projectC , stageUrl: [inherited] , site: scp://bar/projectC directory /dirA/dirD artifact: projectD, parent: projectE, url: http://bar/projectD , stageUrl: [inherited] , site: scp://bar/projectD directory /dirE artifact: projectE, parent: null, url: http://foo/projectE , stageUrl: [file:///stagingLoc/, site: scp://foo/projectE gets site:deployed to host: foo, directory: / host: foo, directory: /projectB host: bar, directory: /projectC host: bar, directory: /projectD host: foo, directory: /projectE gets site:staged to:- stagingLoc/projectA stagingLoc/projectA/projectB stagingLoc/projectA/projectC stagingLoc/projectA/projectD stagingLoc/projectE The generation of parent and module links for the stage mode will just use the project::stageURL. the links for deployment mode will use the project::URL. And i guess the new site:stage Mojo will rewrite the links to be stageURL links and then invoke the stage wagon location - we'll need a new site wagon setting as the distributionManagement::site and the project::URL are bound together in their meaning so if we create a new stageURL we well require a new distributionManagement::stageSite setting (which would be set to file::/someLoc in most cases). Phew! What a lot of words for something so simple! WDYT? Do you see the problem we have?
          Hide
          Gopal Patwa added a comment -

          I am using this type of relative url link for all sub modules in staging, so it can work with parent site and it works

          <url>../../<module-name>/target/site</url>

          John, Thanks for all your work

          Show
          Gopal Patwa added a comment - I am using this type of relative url link for all sub modules in staging, so it can work with parent site and it works <url>../../<module-name>/target/site</url> John, Thanks for all your work
          Hide
          Vincent Siveton added a comment -

          John,

          I liked your comments, and ideas, specially the "stage idea". Much appreciated.

          To resolve the testing pb, I propose to define a new Mojo that will "simulate" a deployment.

          SimulateDeployMojo should have a stagingDirectory as parameter.
          SimulateDeployMojo could replace project.url by an hardcode url based on the stagingDirectory (I mean file schema)

          Details :
          Multiproject
          distributionManagement.site.url=scp://myHost/www/myPath/multiproject/
          stagingDirectory=C:\testingsite

          Multiproject.framework1
          distributionManagement.site.url=scp://myHost/www/myPath/framework1/

          Multiproject.framework2
          distributionManagement.site.url=scp://myOtherHost/www/myOtherPath/framework2/

          If distributionManagement.site.url is never defined, try to use the project.url.

          The Mojo will create the following structure and all links (parent project and modules) should be hardcode.
          C:\testingsite

          -myHost
          -www
          --myPath
          --multiproject
          --framework1
          -myOtherHost
          -www
          --myOtherPath
          --framework2

          WDYT?

          Show
          Vincent Siveton added a comment - John, I liked your comments, and ideas, specially the "stage idea". Much appreciated. To resolve the testing pb, I propose to define a new Mojo that will "simulate" a deployment. SimulateDeployMojo should have a stagingDirectory as parameter. SimulateDeployMojo could replace project.url by an hardcode url based on the stagingDirectory (I mean file schema) Details : Multiproject distributionManagement.site.url=scp://myHost/www/myPath/multiproject/ stagingDirectory=C:\testingsite Multiproject.framework1 distributionManagement.site.url=scp://myHost/www/myPath/framework1/ Multiproject.framework2 distributionManagement.site.url=scp://myOtherHost/www/myOtherPath/framework2/ If distributionManagement.site.url is never defined, try to use the project.url. The Mojo will create the following structure and all links (parent project and modules) should be hardcode. C:\testingsite -myHost -www --myPath --multiproject --framework1 -myOtherHost -www --myOtherPath --framework2 WDYT?
          Hide
          John Allen added a comment -

          Hi Vincent,

          Yeah i think this is a more approrpiate approach, especially as its only intended for testing.

          So the key to the the simulate mode is that all projects referenced by the reactor env. will be expected to share a common URL root and this root will be set by a plugin config rather than try and use the main POM.

          This would be great and would solve another problem i have with my CI based builds - In CI builds i still wnat to build the sites to allow project teams to access the latest SNAPSHOT javadocs, review code coverage etc without me having to deploy the site to the 'offical' location (a task I associate with a project deployment, not just CI builds)

          I think we should also support the deployment of this 'simulated' site to a remote site which leads me to thinking that all this link URL business is pretty much dependent on where we're intending to deploy things to (staged or deployed/published location) so should we make the settings of these URLs something that the deploy operation does as a preparatory action?

          site:site - generate site for deployment but create placeholders for links

          site:stage - set parent and module links to file:// URLs based upon the project's distributionManagement.site details (i.e. exactly as you proposed) and then deploy the site to the location defined by the Mojo config (this supports us scp'ing the staged site to a remote host and implicitly supports the stagingDirectory you proposed)

          site:deploy - set parent and module links to URLs defined the project's real URL details (i.e. as my patch currently assumes) and then deploy the sites as defined by their distributionManagement settings (which must be related to their project.URLs otherwise the POM writer has screwed up )

          We're definately getting their :- WDYT ...

          ps. in regards to naming, staging is a common term for review/testing of a web site. Do we want to just call this site:stage rather than simulate? I know to us its simulating the real site deployment but in terms of business process the user is staging it for testing or local review. Not gonna get religous over about it though

          Show
          John Allen added a comment - Hi Vincent, Yeah i think this is a more approrpiate approach, especially as its only intended for testing. So the key to the the simulate mode is that all projects referenced by the reactor env. will be expected to share a common URL root and this root will be set by a plugin config rather than try and use the main POM. This would be great and would solve another problem i have with my CI based builds - In CI builds i still wnat to build the sites to allow project teams to access the latest SNAPSHOT javadocs, review code coverage etc without me having to deploy the site to the 'offical' location (a task I associate with a project deployment, not just CI builds) I think we should also support the deployment of this 'simulated' site to a remote site which leads me to thinking that all this link URL business is pretty much dependent on where we're intending to deploy things to (staged or deployed/published location) so should we make the settings of these URLs something that the deploy operation does as a preparatory action? site:site - generate site for deployment but create placeholders for links site:stage - set parent and module links to file:// URLs based upon the project's distributionManagement.site details (i.e. exactly as you proposed) and then deploy the site to the location defined by the Mojo config (this supports us scp'ing the staged site to a remote host and implicitly supports the stagingDirectory you proposed) site:deploy - set parent and module links to URLs defined the project's real URL details (i.e. as my patch currently assumes) and then deploy the sites as defined by their distributionManagement settings (which must be related to their project.URLs otherwise the POM writer has screwed up ) We're definately getting their :- WDYT ... ps. in regards to naming, staging is a common term for review/testing of a web site. Do we want to just call this site:stage rather than simulate? I know to us its simulating the real site deployment but in terms of business process the user is staging it for testing or local review. Not gonna get religous over about it though
          Hide
          Vincent Siveton added a comment -

          So, I created a SiteStageMojo (agree with the naming) with stagingDirectory and stagingSiteURL as parameters:

          • stagingDirectory as discussed
          • stagingSiteURL could be scp://www.mycompany.com/www/project/ (ie samething that the distributionManagement.site.url element)

          I will put a new diff file with your proposal and a dummy project.

          BTW, this issue could be related to MNG-983

          Show
          Vincent Siveton added a comment - So, I created a SiteStageMojo (agree with the naming) with stagingDirectory and stagingSiteURL as parameters: stagingDirectory as discussed stagingSiteURL could be scp://www.mycompany.com/www/project/ (ie samething that the distributionManagement.site.url element) I will put a new diff file with your proposal and a dummy project. BTW, this issue could be related to MNG-983
          Hide
          Vincent Siveton added a comment -

          diff file and dummy project

          Show
          Vincent Siveton added a comment - diff file and dummy project
          Vincent Siveton made changes -
          Attachment MNG-661.diff [ 17920 ]
          Attachment site-plugin-multiproject.zip [ 17921 ]
          John Allen made changes -
          Link This issue duplicates MNG-983 [ MNG-983 ]
          Hide
          John Allen added a comment -

          Vincent, the patch seems to be missing the new SiteStage mojo.

          Show
          John Allen added a comment - Vincent, the patch seems to be missing the new SiteStage mojo.
          Hide
          Vincent Siveton added a comment -

          Repost with SiteStageMojo

          Show
          Vincent Siveton added a comment - Repost with SiteStageMojo
          Vincent Siveton made changes -
          Attachment MNG-661.diff [ 17929 ]
          Hide
          John Allen added a comment -

          Thanks Vincent, works a treat!

          I'm using the staged site not only reviewing but also for internal pre-release publications (i.e. CI build generates an internally published site).

          Show
          John Allen added a comment - Thanks Vincent, works a treat! I'm using the staged site not only reviewing but also for internal pre-release publications (i.e. CI build generates an internally published site).
          John Casey made changes -
          Fix Version/s 2.0.2 [ 12107 ]
          Fix Version/s 2.0.1 [ 12000 ]
          Hide
          Vincent Siveton added a comment -

          Applied. Thanks John!

          Show
          Vincent Siveton added a comment - Applied. Thanks John!
          Vincent Siveton made changes -
          Status Reopened [ 4 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          Hide
          patrick OShea added a comment -

          Hi,

          I've been trying to get the parent and child projects linked from the site.
          Luckily you've already done all the work.
          I did make a few small changes to default to the getModulesMenu() and getProjectParentMenu()
          reporting output directory for if the parent\child urls are not set.
          If you would like the changes I can upload a diff of the changes

          Patrick

          Show
          patrick OShea added a comment - Hi, I've been trying to get the parent and child projects linked from the site. Luckily you've already done all the work. I did make a few small changes to default to the getModulesMenu() and getProjectParentMenu() reporting output directory for if the parent\child urls are not set. If you would like the changes I can upload a diff of the changes Patrick
          Hide
          John Allen added a comment -

          re the patch,

          theres a bug in the SiteStageMojo::getStructure() method under windows.

          Windows distribution paths can start with drive prefixes and thus we need to sanitize the ':' as its illegal in the newly generated compound path.

          Dont have a patch as this is a patch on a patch with no revision to compare against but starting at line 157:-

          Repository repository = new Repository( site.getId(), site.getUrl() );
          if ( StringUtils.isEmpty( repository.getBasedir() ) )

          { return repository.getHost(); }

          // might need to sanitize a drive letter under windows (eg. D:)

          String baseDir = repository.getBasedir();

          if ( baseDir.charAt(1) == ':' )
          {
          StringBuffer buffer = new StringBuffer();
          buffer.append( baseDir.charAt( 0 ) );

          if ( baseDir.length() > 3 )

          { buffer.append( baseDir.substring( 2 ) ); }

          baseDir = buffer.toString() ;

          System.out.println( "new baseDir = " + baseDir );
          }

          if ( baseDir.startsWith( "/" ) )

          { return repository.getHost() + baseDir; }
          Show
          John Allen added a comment - re the patch, theres a bug in the SiteStageMojo::getStructure() method under windows. Windows distribution paths can start with drive prefixes and thus we need to sanitize the ':' as its illegal in the newly generated compound path. Dont have a patch as this is a patch on a patch with no revision to compare against but starting at line 157:- Repository repository = new Repository( site.getId(), site.getUrl() ); if ( StringUtils.isEmpty( repository.getBasedir() ) ) { return repository.getHost(); } // might need to sanitize a drive letter under windows (eg. D:) String baseDir = repository.getBasedir(); if ( baseDir.charAt(1) == ':' ) { StringBuffer buffer = new StringBuffer(); buffer.append( baseDir.charAt( 0 ) ); if ( baseDir.length() > 3 ) { buffer.append( baseDir.substring( 2 ) ); } baseDir = buffer.toString() ; System.out.println( "new baseDir = " + baseDir ); } if ( baseDir.startsWith( "/" ) ) { return repository.getHost() + baseDir; }
          Hide
          John Allen added a comment -

          Additionall problem with new staging functionality and accessing uninterpolated parent project attributes.

          project.getParent() returns a project that has not been 'cooked' and thus contains uninterpolated expressions (e.g. $

          {my.var}

          )

          we need to use the reactor projects to find the parent as these have been properly processed.

          Show
          John Allen added a comment - Additionall problem with new staging functionality and accessing uninterpolated parent project attributes. project.getParent() returns a project that has not been 'cooked' and thus contains uninterpolated expressions (e.g. $ {my.var} ) we need to use the reactor projects to find the parent as these have been properly processed.
          Hide
          Brett Porter added a comment -

          John - please create a new issue for your staging site problems

          Show
          Brett Porter added a comment - John - please create a new issue for your staging site problems
          John Allen made changes -
          Link This issue is related to MNG-1874 [ MNG-1874 ]
          Jason van Zyl made changes -
          Key MNG-661 MSITE-54
          Fix Version/s 2.0.3 [ 12107 ]
          Workflow Maven [ 37005 ] jira [ 44244 ]
          Project Maven 2 [ 10500 ] Maven 2.x Site Plugin [ 11146 ]
          Affects Version/s 2.0-alpha-3 [ 11021 ]
          Component/s maven-site-plugin [ 11802 ]
          Type Improvement [ 4 ] Bug [ 1 ]
          Jason van Zyl made changes -
          Workflow jira [ 44244 ] Maven [ 45061 ]
          Brett Porter made changes -
          Workflow Maven [ 45061 ] Maven New [ 52427 ]

            People

            • Assignee:
              Vincent Siveton
              Reporter:
              Yann Le Du
            • Votes:
              15 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: