Hi Ben,
I've got the same problem.
As you've noted the Hudson "Maven-generated site" appears to be the last
pom/module built and not the highest parent. Also, the use of a url based on
${project.groupId} and ${project.artifactId} is ugly.... very ugly.
Especially when you get two level's deep on parents (super ugly, broken
references and unworkable).
My proposed solution would be to derive your site distro url's from a
profile property. You could put this in the hudson user's setting.xml or in
the pom.xml itself (which one is circumstantial). The profile can be
activated from the hudson job.
I would expect the distro url to be a link to the filesystem that is
acutally where the "Maven-generated site" actually resolves too.
Perhaps this would work... I doubt we are the first to encounter this.
Help/Advice would be GREAT :)
On Wed, May 27, 2009 at 6:40 AM, B Smith-Mannschott
<[email protected]>wrote:
> I'm sending this missive to user's lists of both hudson and maven
> because it concerns using these two tools together, and I'll need help
> from both parties to make this work.
>
> Rather than separately site-deploying the sites of the 30 or so maven
> projects hudson is building for me at work, I've decided to take
> advantage of hudson's handy "maven generated site" link. (Now that it
> works again!)
>
> This works quite well for single-module maven builds.
>
> Multi-module builds, not so much.
>
> I have a few multi-module maven projects at work, and here are the
> problems:
>
> (1) Hudson's "maven generated site" link links to one of the
> sub-modules instead of linking to the site of the multi-module pom
> project at the root of the defined working copy.
>
> (2) Even if it *did* link to the correct project, instead of some
> random sub-project, it wouldn't work since links to sub-modules are
> broken.
>
> (3) Links to sub-modules are broken. They expect to find in
> target/site/submodule, what is in fact in submodule/target/site.
>
> (4) Links to sub-modules are not even generated unless it happens that
> the multi-module pom project is also the <parent> of each of the
> submodules. Why this is, is anyone's guess.
>
> (5) They will work, if the site is deployed, but then <url> must be
> defined correctly.
>
> (6) One thing that works, but is ugly is:
> <url>http://example.com/${groupId}/${artifactId}</url> in the
> parent/multi-module pom. The children end up all installing to
> http://example.com/${groupId}/${project.artifactId}/${project.artifactId},
> which is just kind of gross, instead of
> ttp://example.com/${groupId}/${parent.artifactId}/${project.artifactId},
> but I guess that's an effect of the ${} expansion being after, not
> before inheritance is performed.
>
> But, if I deploy the site, I need to separately maintain a page of
> links to those sites, since Hudson's "maven generated site" link does
> not go there, it goes to target/site. I also have a whole separate set
> of URLs to manage, to advertise to my users and to clean up when I
> remove corresponding build jobs. Messy.
>
> I'm trying to simplify my life, not complicated it.
>
>
> Is there some way I can get my multi-module projects to produce a site
> which is accessible through hudson and which makes submodules
> available? Alternately, perhaps it would be possible to somehow
> intelligently combine the project reports from the various submodules
> and merge them all into the site of the multi-module build.
>
>
> I've reached the point now where I'm tempted to just break out beat
> the problem into submission with a generous helping of shell
> scripting, but that doesn't seem very 'mavenesque'.
>
> Has anyone out there already solved this, or a similar problem?
>
> // Ben
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
