[ 
https://issues.apache.org/jira/browse/MNG-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hervé Boutemy updated MNG-3344:
-------------------------------
    Description: 
As requested in MSITE-91 and its various duplicates, the input location for the 
site generation should be configurable. Currently, this is realized by a 
configuration parameter (siteDirectory) for the maven-site-plugin itself but I 
argue that this is not sufficient/robust for all cases. The problem is that the 
plugin cannot access its configuration in ancestor POMs and hence can only 
guess.

For example, take the following multi-module scenario:
{noformat}  project-parent/
    doc/
      site.xml
    project-module/
      src/
        site/
          site.xml{noformat}
Let us ignore the fact that such is layout is unusual, weird, bad-practice or 
whatever you would like to call it. The point is, it should be possible. The 
important aspect of the example is that both POMs will need to use a different 
configuration of the maven-site-plugin to find the site descriptor (and related 
files). The parent POM will have siteDirectory=doc while the module POM will 
have siteDirectory=src/site.

Now consider the plugin's steps when building the site for project-module. 
>From the plugin configuration in "project-module/pom.xml", it knows to search 
the site descriptor for the sub project in "src/site". To apply inheritance, 
the plugin then needs to locate the site descriptor of the parent project. Ups. 
The plugin cannot access the corresponding plugin configuration in 
"project-parent/pom.xml". So it can only assume that the parent uses the same 
directory layout for the site as the current sub module.

Having a dedicated POM element for the site files, e.g. 
${project.reporting.siteDirectory}, would allow the maven-site-plugin to 
properly determine the location of the site descriptor of any ancestor project. 
The super POM can default this element to "src/site" to get the usual behavior.

  was:
As requested in MSITE-91 and its various duplicates, the input location for the 
site generation should be configurable. Currently, this is realized by a 
configuration parameter (siteDirectory) for the maven-site-plugin itself but I 
argue that this is not sufficient/robust for all cases. The problem is that the 
plugin cannot access its configuration in ancestor POMs and hence can only 
guess.

For example, take the following multi-module scenario:
  project-parent/
    doc/
      site.xml
    project-module/
      src/
        site/
          site.xml
Let us ignore the fact that such is layout is unusual, weird, bad-practice or 
whatever you would like to call it. The point is, it should be possible. The 
important aspect of the example is that both POMs will need to use a different 
configuration of the maven-site-plugin to find the site descriptor (and related 
files). The parent POM will have siteDirectory=doc while the module POM will 
have siteDirectory=src/site.

Now consider the plugin's steps when building the site for project-module. 
>From the plugin configuration in "project-module/pom.xml", it knows to search 
the site descriptor for the sub project in "src/site". To apply inheritance, 
the plugin then needs to locate the site descriptor of the parent project. Ups. 
The plugin cannot access the corresponding plugin configuration in 
"project-parent/pom.xml". So it can only assume that the parent uses the same 
directory layout for the site as the current sub module.

Having a dedicated POM element for the site files, e.g. 
${project.reporting.siteDirectory}, would allow the maven-site-plugin to 
properly determine the location of the site descriptor of any ancestor project. 
The super POM can default this element to "src/site" to get the usual behavior.


> Provide new POM element to configure site directory (e.g. "src/site")
> ---------------------------------------------------------------------
>
>                 Key: MNG-3344
>                 URL: https://issues.apache.org/jira/browse/MNG-3344
>             Project: Maven
>          Issue Type: New Feature
>          Components: POM
>    Affects Versions: 2.0.8
>            Reporter: Benjamin Bentmann
>            Priority: Major
>
> As requested in MSITE-91 and its various duplicates, the input location for 
> the site generation should be configurable. Currently, this is realized by a 
> configuration parameter (siteDirectory) for the maven-site-plugin itself but 
> I argue that this is not sufficient/robust for all cases. The problem is that 
> the plugin cannot access its configuration in ancestor POMs and hence can 
> only guess.
> For example, take the following multi-module scenario:
> {noformat}  project-parent/
>     doc/
>       site.xml
>     project-module/
>       src/
>         site/
>           site.xml{noformat}
> Let us ignore the fact that such is layout is unusual, weird, bad-practice or 
> whatever you would like to call it. The point is, it should be possible. The 
> important aspect of the example is that both POMs will need to use a 
> different configuration of the maven-site-plugin to find the site descriptor 
> (and related files). The parent POM will have siteDirectory=doc while the 
> module POM will have siteDirectory=src/site.
> Now consider the plugin's steps when building the site for project-module. 
> From the plugin configuration in "project-module/pom.xml", it knows to search 
> the site descriptor for the sub project in "src/site". To apply inheritance, 
> the plugin then needs to locate the site descriptor of the parent project. 
> Ups. The plugin cannot access the corresponding plugin configuration in 
> "project-parent/pom.xml". So it can only assume that the parent uses the same 
> directory layout for the site as the current sub module.
> Having a dedicated POM element for the site files, e.g. 
> ${project.reporting.siteDirectory}, would allow the maven-site-plugin to 
> properly determine the location of the site descriptor of any ancestor 
> project. The super POM can default this element to "src/site" to get the 
> usual behavior.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to