-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
Powered by SuggestiMate
After running goals "clean install site" in a Maven2 build, project home page
shows a link called "Maven-generated site". This links gives a 404 because it
is missing project-info.html off the end of the URL.
[JENKINS-6681] Maven-generated site link gives 404
I notice a similar problem in Hudson 1.357. I thought it was because I had two modules. I noticed that the three projects (the top and the two modules) are available at
http://closettop.homelinux.org:8080/job/maven-build/site/allArgoUMLProjects/
http://closettop.homelinux.org:8080/job/maven-build/site/argouml-core-model/
http://closettop.homelinux.org:8080/job/maven-build/site/argouml-actionscript3/
but the link from the job pages point to
http://closettop.homelinux.org:8080/job/maven-build/site/?
that doesn't exist.
For me, the best solution would probably be if the maven site function would create a "summary site" merging the information from all sub-sites and possibly also providing links to them. This is then a maven problem to solve. But Hudson need to maintain the links correctly when copying and solve the problem of providing the link to the "summary site".
In our case (see my earlier comment), documentation links are broken for all our projects.
Whether or not we have modules in them doesn't matter.
It seems to me that the problem is that Maven does not generate a index.html file in these cases. And I think that it is a Maven only problem, and not an issue in Jenkins.
To generate the index.html file, you could probably add an apt/index.apt, or if you use Maven 3 in Jenkins, perhaps you need to fix your pom.xml configuration: see Maven docs.
As it is a Maven problem, I suggest to close this Jenkins issue as Won't fix.
What do you think?
I'm having this same issue with Jenkins 1.446 and Maven 3.0.3. I have found that if I set up the Jenkins job to run "mvn deploy site", then the Maven generated site link is broke and I need to append the artifactId to the URL. I also notice in the jobs/job_name/site directory that there is an artifactId subdirectory and the site contents are in there rather than in the site directory.
However, if I run "mvn package deploy", the Maven generated site link works just fine. Furthermore, all of the files that previously appeared in jobs/job_name/site/artifactId now appear in jobs/job_name/site.
I checked the workspace/job_name/site directory in both cases, and both times the site files, including index.html, were generated in that directory.
Jenkins copies the site files from workspace/job_name/site, so why, with the exact same mvn pom.xml, doing the same build, does Jenkins in one case copy the generated site to one location, and in the other case copies the site to a different location?
So I disagree very much with evernat - there is an index.html file, it was generated in both cases. The behavior points to a Jenkins problem.
I have the exact same problem like Peter. Maven 3, and Jenkins 1.447.1
I spent some time looking into this problem and found out that Jenkins looks to see if the site's index file is at <location-of-pom>/target/site/index.html. If it is, then the generated site link works as expected for a regular (not multi-module) Maven build. If the index file is not located there, then Jenkins assumes that it is doing a multi-module build and thus it prefixes the artifactId to the path for the site; thus each module within the multi-module build can have its own site with the master module providing a main index page with links to the individual module's sites. In the case of our builds, one of the Maven plugins moved the POM (to target/pom.xml) and this plugin was invoked just before the install phase. Once we corrected this (we configured the plugin to update the POM in place), the generated site link now works again. So from my point of view, this problem is solved for me, no fix is necessary. I hope my analysis helps others.
Okay. I see the problem for my case –
I'm using RTC Jazz SCM... due to the way the SCM system works, the checkouts are like so:
workspace/<job-name>/<SCM-component-name>/pom.xml
But the code for MavenSiteArchiver.getModuleName() is checking if the workspace name ("workspace/<job-name>") equals the pomBaseDir ("workspace/<job-name>/<SCM-component-name>").
It should be checking if rootPOM equals pom instead. (Where rootPOM is from config.xml's /maven2-moduleset/rootPOM element).
Link to MavenSiteARchiver.getModuleName():
Another issue is that something should come along afterwards and if there isn't a root index.html in the sites/ directory on the Jenkins server it should provide an index of modules.
Either one of the changes above would fix my problem, but the second one would at least not leave people with different problems out in the cold.
We're seeing this (or something very similar) too, with Hudson 1.358 on Windows.
Here's an example URL generated by Hudson:
http://sthinfra06:8080/job/apcore-main/site/?
What it should say is one of:
http://sthinfra06:8080/job/apcore-main/site/apcore
http://sthinfra06:8080/job/apcore-main/site/apcore/
"apcore-main" is the Hudson job name.
"apcore" is the Maven artifact ID for this project.
Hudson is installed in d:\hudson, and the on-disk path to the generated site is d:\hudson\jobs\apcore-main\site\apcore.