You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "John Allen (JIRA)" <ji...@codehaus.org> on 2008/12/06 13:59:19 UTC
[jira] Created: (MRELEASE-395) release:stage does not properly
compute new distroManagement.site.URL or project.URLs for projects
release:stage does not properly compute new distroManagement.site.URL or project.URLs for projects
--------------------------------------------------------------------------------------------------
Key: MRELEASE-395
URL: http://jira.codehaus.org/browse/MRELEASE-395
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-8
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.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-594) release:stage does not properly compute
new distroManagement.site.URL or project.URLs for projects
Posted by "Lukas Theussl (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MSITE-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lukas Theussl closed MSITE-594.
-------------------------------
Resolution: Incomplete
Assignee: Lukas Theussl
John: I'm closing this as incomplete as I am unable to reproduce without detailed version information of the plugins involved. Note that current site-plugin-2.3 has seen several fixes wrt stage(-deploy), see in particular MSITE-534, MSITE-535, MSITE-537 and related tickets. Please test with latest plugins and open another jira with a reproducible test case if the issue persists.
> 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
> Assignee: Lukas Theussl
> 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
[jira] Updated: (MRELEASE-395) release:stage does not properly
compute new distroManagement.site.URL or project.URLs for projects
Posted by "Arnaud Heritier (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRELEASE-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Arnaud Heritier updated MRELEASE-395:
-------------------------------------
Component/s: stage
> release:stage does not properly compute new distroManagement.site.URL or project.URLs for projects
> --------------------------------------------------------------------------------------------------
>
> Key: MRELEASE-395
> URL: http://jira.codehaus.org/browse/MRELEASE-395
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: stage
> Affects Versions: 2.0-beta-8
> 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.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-594) release:stage does not properly
compute new distroManagement.site.URL or project.URLs for projects
Posted by "John Allen (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MSITE-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272022#comment-272022 ]
John Allen commented on MSITE-594:
----------------------------------
Although it has been a while a quick re-reading of my original description would indicate that the issue does lie with the release:deploy mojo as it is directly manipulating the various URLS of the project it is trying to deploy before calling upon another plugins to carry out their function. It is thus the responsibility of the deploy mojo to do this properly for all required fields for the delegated plugins to work properly
I.e. when considering if this is or isnt in the realm of the deploy plugin to address, consider:
It works fine and as designed when not being called by release:deploy
It doesnt work when being called by release:deploy
> 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
[jira] Moved: (MSITE-594) release:stage does not properly compute
new distroManagement.site.URL or project.URLs for projects
Posted by "Stephen Connolly (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Commented: (MSITE-594) release:stage does not properly
compute new distroManagement.site.URL or project.URLs for projects
Posted by "Stephen Connolly (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MSITE-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272002#comment-272002 ]
Stephen Connolly commented on MSITE-594:
----------------------------------------
Not an issue with release plugin as release plugin just plain delegates to site:stage-deploy
> 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