Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-2531

Links for generated sites in Maven multi-module project are incorrect.

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • maven-plugin
    • None
    • Platform: PC, OS: Linux

    Description

      When Maven2 project is setup to generate the Maven site, Hudson displays
      'Maven-generated site' links on the project page. If the project is a
      multi-module Maven project then that link points to a site generated for one of
      the modules and not the project itself.
      Maven will generate the sites individually for every module but links between
      parent modules and child modules will only work after the site has been deployed
      or staged.
      As a suggestion, the 'Maven-generated site' link should point to that module's site.

      Attachments

        Issue Links

          Activity

            cristalp cristalp added a comment -

            I would like to hijack this bug

            The first issue (project shows the site of the last generated module) is
            actually a duplicate of bug 2245, and the patch solves the problem, including
            navigation to the modules in the project's Maven site.

            However, I think that Hudson should call the site generation for the project and
            all of its modules separately and store the Maven site separately. So, the
            project would have a "Maven generated site", and then every module should also
            show its own "Maven generated site".

            cristalp cristalp added a comment - I would like to hijack this bug The first issue (project shows the site of the last generated module) is actually a duplicate of bug 2245, and the patch solves the problem, including navigation to the modules in the project's Maven site. However, I think that Hudson should call the site generation for the project and all of its modules separately and store the Maven site separately. So, the project would have a "Maven generated site", and then every module should also show its own "Maven generated site".
            at at added a comment -

            The best for me would be that hudson generates the site for the whole project
            and then the links point to specific modules in the generated site.

            at at added a comment - The best for me would be that hudson generates the site for the whole project and then the links point to specific modules in the generated site.
            skaze skaze added a comment -

            please note that having hudson expose the maven generated site in target/site is
            only useful for resources local to that site. we have changed the site plugin in
            2.0-beta-5 to generate relative links for things such as the parent project,
            child module projects and even for site's skin resources. These relative URLs
            are created based upon the DEPLOYED location of the site and will never resolve
            while the site is sat in target/site. Only once the sites are deployed, either
            via site:deploy or site:stage (to deploy it to a local area rather than the
            public <distroManagement.site> location) will the site's links actually be valid.

            In IMHO i think the issue raised in this ticket is valid, if you're going to
            expose the target/site location for a maven project, it should be correct in
            terms of the module being viewed.

            skaze skaze added a comment - please note that having hudson expose the maven generated site in target/site is only useful for resources local to that site. we have changed the site plugin in 2.0-beta-5 to generate relative links for things such as the parent project, child module projects and even for site's skin resources. These relative URLs are created based upon the DEPLOYED location of the site and will never resolve while the site is sat in target/site. Only once the sites are deployed, either via site:deploy or site:stage (to deploy it to a local area rather than the public <distroManagement.site> location) will the site's links actually be valid. In IMHO i think the issue raised in this ticket is valid, if you're going to expose the target/site location for a maven project, it should be correct in terms of the module being viewed.
            ddlipsey ddlipsey added a comment -

            I think this would be better resolved by an enhancement. The site handling is in
            my opinion a case where Hudson has tried to achieve more than it should.
            Preferably I should be able to set the 'Maven Generated Site' URL to any URL of
            my choosing and do so at all levels (Project/Module). The Maven site plugin
            allows me to deploy anywhere which could be another server or some default site
            directory under .hudson on my CI server. However its done, I'd prefer to handle
            deployment via my Maven settings and then just configure Hudson to point to
            where I have deployed.

            ddlipsey ddlipsey added a comment - I think this would be better resolved by an enhancement. The site handling is in my opinion a case where Hudson has tried to achieve more than it should. Preferably I should be able to set the 'Maven Generated Site' URL to any URL of my choosing and do so at all levels (Project/Module). The Maven site plugin allows me to deploy anywhere which could be another server or some default site directory under .hudson on my CI server. However its done, I'd prefer to handle deployment via my Maven settings and then just configure Hudson to point to where I have deployed.
            at at added a comment -

            I totally agree that site generation is something that Hudson doesn't have to
            do. I think it might be a good candidate for a separate project configuration
            item like the 'Deploy artifacts to Maven repository' checkbox.
            It should be doable as a plugin too.

            at at added a comment - I totally agree that site generation is something that Hudson doesn't have to do. I think it might be a good candidate for a separate project configuration item like the 'Deploy artifacts to Maven repository' checkbox. It should be doable as a plugin too.
            abayer Andrew Bayer added a comment -

            Taking issue.

            abayer Andrew Bayer added a comment - Taking issue.
            abayer Andrew Bayer added a comment -

            I think the Maven site integration with Hudson is pretty much unworkable - given
            a choice, I'd remove it completely. It just doesn't make sense in relation to
            Hudson. That said, if someone wants to write a plugin along the lines of what at
            mentions, feel free.

            abayer Andrew Bayer added a comment - I think the Maven site integration with Hudson is pretty much unworkable - given a choice, I'd remove it completely. It just doesn't make sense in relation to Hudson. That said, if someone wants to write a plugin along the lines of what at mentions, feel free.
            cristalp cristalp added a comment -

            I think that Hudson should either
            a) ignore the Maven site completely (which would be a pity)

            or

            b) if it's not possible to handle multi-module sites correctly, at least be
            able to calculate the project's URL based on the site configuration of Maven

            cristalp cristalp added a comment - I think that Hudson should either a) ignore the Maven site completely (which would be a pity) or b) if it's not possible to handle multi-module sites correctly, at least be able to calculate the project's URL based on the site configuration of Maven
            blidgey blidgey added a comment -

            I would vote for linking to the generated site URL, or at least making the option to link to the generated site URL or to the local copy. We deploy our sites to a server anyway, so the maven site stored inside Hudson is sort of irrelevant anyway.

            blidgey blidgey added a comment - I would vote for linking to the generated site URL, or at least making the option to link to the generated site URL or to the local copy. We deploy our sites to a server anyway, so the maven site stored inside Hudson is sort of irrelevant anyway.

            Code changed in hudson
            User: : mfriedenhagen
            Path:
            trunk/hudson/main/maven-plugin/src/main/java/hudson/maven/reporters/MavenSiteArchiver.java
            trunk/hudson/main/test/src/test/java/hudson/maven/MavenProjectTest.java
            trunk/hudson/main/test/src/test/resources/hudson/maven/maven-multimodule-site.zip
            http://jenkins-ci.org/commit/28369
            Log:
            Fixed JENKINS-2531 by storing sites for multimodule projects.
            Simple projects with one POM will find the site directly beneath

            {@code site}.
            For multi module projects the project whose pom is referenced in the configuration (i.e. the {@link MavenBuild#getParentBuild()} will be recorded to
            the {@code site}

            directory, module projects' sites will be stored beneath {@code site/${moduleProject.artifactId}}.

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : mfriedenhagen Path: trunk/hudson/main/maven-plugin/src/main/java/hudson/maven/reporters/MavenSiteArchiver.java trunk/hudson/main/test/src/test/java/hudson/maven/MavenProjectTest.java trunk/hudson/main/test/src/test/resources/hudson/maven/maven-multimodule-site.zip http://jenkins-ci.org/commit/28369 Log: Fixed JENKINS-2531 by storing sites for multimodule projects. Simple projects with one POM will find the site directly beneath {@code site}. For multi module projects the project whose pom is referenced in the configuration (i.e. the {@link MavenBuild#getParentBuild()} will be recorded to the {@code site} directory, module projects' sites will be stored beneath {@code site/${moduleProject.artifactId}}.

            People

              mfriedenhagen Mirko Friedenhagen
              at at
              Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: