[
https://jira.codehaus.org/browse/MSITE-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly moved MRELEASE-395 to MSITE-594:
-------------------------------------------------
Component/s: (was: stage)
site:stage(-deploy)
Affects Version/s: (was: 2.0-beta-8)
Key: MSITE-594 (was: MRELEASE-395)
Project: Maven 2.x and 3.x Site Plugin (was: Maven 2.x Release
Plugin)
> release:stage does not properly compute new distroManagement.site.URL or
> project.URLs for projects
> --------------------------------------------------------------------------------------------------
>
> Key: MSITE-594
> URL: https://jira.codehaus.org/browse/MSITE-594
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:stage(-deploy)
> Reporter: John Allen
> Priority: Blocker
>
> In the case where you have a multi-module project and each module has its own
> distributionManagement.site.url which is common with projects that like their
> sites to be version numbered (see example beolw) the release:stage plugin
> fails to get the project's site properly deployed. From a brief look it seems
> release:sxtage is only computing a new URL for the owning project and not all
> the child projects. What's more it looks like its changing the site
> deployment URL and not the project's corresponding project URL. This results
> in the site deployment for children going to their original pom.xml specific
> locations regardless of them being 'staged' (i.e. they're not staged, they've
> just gone live!). Nearly as bad is that all the relative links for connecting
> modules and parents and banners together are broken too, as they are based
> upoin the project.URL which hasnt been touched by the release:stage mojo.
> site:stage makes a better fist of this, basically you need to remap the
> entire URL domain (site distro and project url) to be under some other parent
> space for you to successfully stage sites (see site:stage)
> This kind of mistake has come up in the past, simply put a project can define
> all its own settings for everything so anything that makes assumptions based
> on inheritence or 'defaults' is just gonna break the system.
> Example of how sub-project's defining their own site deployemtn and project
> URL information:
> {noformat}
> <site>
>
> <url>dav:https://example.com/maven/sites/${mvn.repoName}/${project.groupId}/${project.artifactId}/${project.version}</url>
> </site>
> <url>http://example.com/maven/sites/${mvn.repoName}/${project.groupId}/${project.artifactId}/${project.version}/</url>
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
