inherited site.xml files are interpolated with the originating project's model values and not the consumer project's values

This goes both for site.xml files resolved from the reactor as for files resolved from a repository.
The site.xml attachments in the repository are already interpolated. Since they're primarily meant
for inheritance I think they should not be interpolated before they're deployed.

Unassigning as it is currently impossible to first merge DecorationModels
and then interpolate them as the last step. A system like MavenProject
inheritance and interpolation (i.e. recursively check and update the model
after it's been marshalled) is necessary to support this.

Perhaps modello could be enhanced with some new features to support this:

• specify inheritance order (parent over child or vice versa)
• generate a model 'tree walker' to interpolate values.

A quick hack is possible: don't interpolate the strings before they're marshalled
into Model objects. Then merge the Model objects for inheritance handling.
Then serialize to a StringWriter. Then interpolate that string, and finally
re-parse the string into a Model object tree. It might even be faster than the current
implementation.

If the dev team think this latter approach is the way to go for now I'll implement it.

Hi Kenney,

Where do we stand on this? As far as i can tell the whole site inheritance stuff is unusable due to all the bugs and strange behavours

In regards to the multiple parent items appearing in the final leaf site, as a quick hack I have removed the populateParentMenu and populateModulesMenu calls from attach-descriptor mojo that resulted in the deployed site.xml being modified before attachment and moved the populateParentMenu from within the recursive getDecorationModel to its caller so we now only ever get one parent item in each project's site. Wasnt the menu::inheritedRef stuff supposed to handle all this?

I think I'm experiencing this issue or one related to it. The projects in our organization defer their versioning to our release system. To do this our pom.xml files all have their version as "$

" instead of the substituted value. The only thing this currently screws up is the site generation since the maven-site-plugin attempts to download the parent's site.xml using this value rather than the correct version number for the parent, which can be found in the parent element in the originating pom.xml or if that value is RELEASE, in the parent's maven-metadata.xml. Any chance this can be fixed to use the value from one of those two locations instead of directly from the parent's pom.xml?