[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lennart Jörelid updated MSITE-669:
--
Attachment: sample.zip
Site sample
> site:stage creates incorrect structure when module paths contains sets of
> "../"
> ---
>
> Key: MSITE-669
> URL: https://jira.codehaus.org/browse/MSITE-669
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links, site:stage(-deploy)
>Affects Versions: 3.1, 3.2
>Reporter: Lennart Jörelid
>Assignee: Lukas Theussl
> Attachments: sample.zip
>
>
> Given the module definitions given below, the site:stage goal produces sets
> of maps relative to the staging directory - i.e. outside of the target
> directory.
> {code:xml}
>
> ../../validation/validation-api
> ../../validation/validation-aspect
> ../parent
>
> {code}
> The staged site should be fully included within the staging directory. It
> would appear that relativization of links for site:stage should take special
> links into consideration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315809#comment-315809
]
Lennart Jörelid commented on MSITE-669:
---
As far as I can tell, your assumption does not seem to be correct.
Attached a sample where all subprojects have well-formed distributionManagement
urls.
The staging site is broken in 2 ways:
* The navigation links do not point correctly to their parent
* The staging documents are not contained within the target/staging directory
> site:stage creates incorrect structure when module paths contains sets of
> "../"
> ---
>
> Key: MSITE-669
> URL: https://jira.codehaus.org/browse/MSITE-669
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links, site:stage(-deploy)
>Affects Versions: 3.1, 3.2
>Reporter: Lennart Jörelid
>Assignee: Lukas Theussl
> Attachments: sample.zip
>
>
> Given the module definitions given below, the site:stage goal produces sets
> of maps relative to the staging directory - i.e. outside of the target
> directory.
> {code:xml}
>
> ../../validation/validation-api
> ../../validation/validation-aspect
> ../parent
>
> {code}
> The staged site should be fully included within the staging directory. It
> would appear that relativization of links for site:stage should take special
> links into consideration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315809#comment-315809
]
Lennart Jörelid edited comment on MSITE-669 at 12/17/12 2:41 AM:
-
As far as I can tell, your assumption does not seem to be correct.
Attached a sample where all subprojects have well-formed distributionManagement
urls.
The staging site is broken in 2 ways:
* The navigation links do not point correctly to their parent
* The staging documents are not contained within the target/staging directory
I would recommend building the standard mvn clean site site:stage within the
supplied sample.zip project structure.
Then open the index.html of the target/staging/ directory in the root project.
Also note that some of the documents are strewn within the project root of the
bar subproject; i.e.
not contained within the foo/target/staging directory.
was (Author: l...@jguru.se):
As far as I can tell, your assumption does not seem to be correct.
Attached a sample where all subprojects have well-formed distributionManagement
urls.
The staging site is broken in 2 ways:
* The navigation links do not point correctly to their parent
* The staging documents are not contained within the target/staging directory
> site:stage creates incorrect structure when module paths contains sets of
> "../"
> ---
>
> Key: MSITE-669
> URL: https://jira.codehaus.org/browse/MSITE-669
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links, site:stage(-deploy)
>Affects Versions: 3.1, 3.2
>Reporter: Lennart Jörelid
>Assignee: Lukas Theussl
> Attachments: sample.zip
>
>
> Given the module definitions given below, the site:stage goal produces sets
> of maps relative to the staging directory - i.e. outside of the target
> directory.
> {code:xml}
>
> ../../validation/validation-api
> ../../validation/validation-aspect
> ../parent
>
> {code}
> The staged site should be fully included within the staging directory. It
> would appear that relativization of links for site:stage should take special
> links into consideration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lennart Jörelid reopened MSITE-669:
---
Attached a small set of maven projects illustrating the problem.
> site:stage creates incorrect structure when module paths contains sets of
> "../"
> ---
>
> Key: MSITE-669
> URL: https://jira.codehaus.org/browse/MSITE-669
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links, site:stage(-deploy)
>Affects Versions: 3.1, 3.2
>Reporter: Lennart Jörelid
>Assignee: Lukas Theussl
> Attachments: sample.zip
>
>
> Given the module definitions given below, the site:stage goal produces sets
> of maps relative to the staging directory - i.e. outside of the target
> directory.
> {code:xml}
>
> ../../validation/validation-api
> ../../validation/validation-aspect
> ../parent
>
> {code}
> The staged site should be fully included within the staging directory. It
> would appear that relativization of links for site:stage should take special
> links into consideration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315809#comment-315809
]
Lennart Jörelid edited comment on MSITE-669 at 12/17/12 2:45 AM:
-
As far as I can tell, your assumption does not seem to be correct.
Attached a sample where all subprojects have well-formed distributionManagement
urls.
The staging site navigation seems broken:
* The navigation links do not point correctly to their parent
I would recommend building the standard mvn clean site site:stage within the
supplied sample.zip project structure.
Then open the index.html of the target/staging/ directory in the root project
and start navigating.
was (Author: l...@jguru.se):
As far as I can tell, your assumption does not seem to be correct.
Attached a sample where all subprojects have well-formed distributionManagement
urls.
The staging site is broken in 2 ways:
* The navigation links do not point correctly to their parent
* The staging documents are not contained within the target/staging directory
I would recommend building the standard mvn clean site site:stage within the
supplied sample.zip project structure.
Then open the index.html of the target/staging/ directory in the root project.
Also note that some of the documents are strewn within the project root of the
bar subproject; i.e.
not contained within the foo/target/staging directory.
> site:stage creates incorrect structure when module paths contains sets of
> "../"
> ---
>
> Key: MSITE-669
> URL: https://jira.codehaus.org/browse/MSITE-669
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links, site:stage(-deploy)
>Affects Versions: 3.1, 3.2
>Reporter: Lennart Jörelid
>Assignee: Lukas Theussl
> Attachments: sample.zip
>
>
> Given the module definitions given below, the site:stage goal produces sets
> of maps relative to the staging directory - i.e. outside of the target
> directory.
> {code:xml}
>
> ../../validation/validation-api
> ../../validation/validation-aspect
> ../parent
>
> {code}
> The staged site should be fully included within the staging directory. It
> would appear that relativization of links for site:stage should take special
> links into consideration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-132) Cannot configure multiple executions (ie. cpd, pmd) independantly
[ https://jira.codehaus.org/browse/MPMD-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315815#comment-315815 ] Dennis Lundberg commented on MPMD-132: -- If you take a closer look at the documentation you will see that the "check" goal does not have the "rulesets" configuration option. http://maven.apache.org/plugins/maven-pmd-plugin/check-mojo.html I'll try to explain what is happening here. In the profile "with-pmd-and-cpd" you do not configure directly under the plugin configuration, but rather under the execution. This means that the configuration is only available to the execution of the "check" report goal. That goal in turn calls the "pmd" goal, but that goal does not inherit the configuration. In the profile "with-pmd-that-works" you configure directly under the plugin configuration. This means that the configuration is inherited by the "check" report goal. When that goal in turn calls the "pmd" goal it will have the configuration. In order for this to work the way you want it to, one would need to add a section within the profile that configures the for the "pmd" goal correctly. Unfortunately this will not work either, because of the structure of maven-pmd-plugin and the way Maven works. This is partly because you cannot tie a report to an execution in Maven and partly because the cpd and pmd parts of this plugin shares their configuration. > Cannot configure multiple executions (ie. cpd, pmd) independantly > - > > Key: MPMD-132 > URL: https://jira.codehaus.org/browse/MPMD-132 > Project: Maven 2.x PMD Plugin > Issue Type: Bug > Components: CPD, PMD >Affects Versions: 2.5 >Reporter: Derek Lewis > Attachments: maven-pmd-plugin-bug.zip > > > When trying to configure cpd and pmd differently (ie. includeTests for PMD, > but not for CPD), the plugin does not honour configuration within the > execution. > For example, if a ruleset file is specified in within the > , it is ignored, and the default ruleset is applied. > In the testcase: > $ mvn install > ^ This fails with a PMD error, because the ruleset is ignored due to the > being within the > $ mvn install -Pwith-pmd-that-works > ^ This passes, because it is a profile where the is within > , not -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315817#comment-315817
]
Lukas Theussl commented on MSITE-669:
-
The problem here is that the site plugin needs one top-level base url that
serves as reference for relative links of all sub-projects. The current
assumption is that this base url is the one defined in the top-level reactor
project. In your project layout this is not the case, some modules get deployed
'above' the top reactor project, i.e. 'beyond root'. So it's not the module
directory layout per se that causes the trouble, but the relative deployment
location of the sub-projects. If you can re-define the urls such that all
modules get deployed to sub-urls of the top project, everything should work.
As a fix for the site plugin, the only solution I can see for this particular
problem is to extract the actual top-level url by looping over all modules
before processing anything. However, first I would encourage you to re-think
your project layout, I would not be surprised if your setup would lead to all
kind of other troubles as well.
> site:stage creates incorrect structure when module paths contains sets of
> "../"
> ---
>
> Key: MSITE-669
> URL: https://jira.codehaus.org/browse/MSITE-669
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links, site:stage(-deploy)
>Affects Versions: 3.1, 3.2
>Reporter: Lennart Jörelid
>Assignee: Lukas Theussl
> Attachments: sample.zip
>
>
> Given the module definitions given below, the site:stage goal produces sets
> of maps relative to the staging directory - i.e. outside of the target
> directory.
> {code:xml}
>
> ../../validation/validation-api
> ../../validation/validation-aspect
> ../parent
>
> {code}
> The staged site should be fully included within the staging directory. It
> would appear that relativization of links for site:stage should take special
> links into consideration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-158) Relative file name doesn't work when specifying ruleset
[
https://jira.codehaus.org/browse/MPMD-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MPMD-158:
-
Attachment: MPMD-158.zip
This sample project works for me. How does it differ from what you are using?
> Relative file name doesn't work when specifying ruleset
> ---
>
> Key: MPMD-158
> URL: https://jira.codehaus.org/browse/MPMD-158
> Project: Maven 2.x PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 2.7.1
> Environment: Windows 7
>Reporter: Taras Pushyk
> Attachments: MPMD-158.zip
>
>
> When ruleset specified as follows:
> {code}
>
> org.apache.maven.plugins
> maven-pmd-plugin
> 2.7.1
>
> false 100 1.5
>
>../config/basic.xml
>
>
>
> {code}
> File is not resolved. Also following message appears on console:
> [DEBUG] The resource '../config/basic.xml' was not found with resourceLoader
> org.codehaus.plexus.resource.loader.FileResourceLoader.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-84) Maven PMD plugin does not honour exclude-pattern in PMD rulesets
[ https://jira.codehaus.org/browse/MPMD-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MPMD-84. --- Resolution: Fixed This has been fixed, but I don't know in which version. I have projects that successfully uses to exclude files from PMD. > Maven PMD plugin does not honour exclude-pattern in PMD rulesets > > > Key: MPMD-84 > URL: https://jira.codehaus.org/browse/MPMD-84 > Project: Maven 2.x PMD Plugin > Issue Type: Bug > Components: PMD >Affects Versions: 2.4 >Reporter: Denis Cabasson > Attachments: mpmd84-20100716.patch > > > According to PMD documentation, exclude-patterns should be independendant on > the program running PMD : > http://pmd.sourceforge.net/howtomakearuleset.html > But Maven scans through all the files, not taking into account the > exclude-patterns and thus including files that shouldn't be. > THose file should be filtered out by the maven plugin -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-80) maven-pmd-plugin should generate only one pmd.xml file
[ https://jira.codehaus.org/browse/MPMD-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315823#comment-315823 ] Dennis Lundberg commented on MPMD-80: - Since the next version of the plugin will be 3.0, I suggest that we break backwards compatibility now. Let us add a configuration called "includePmdXmlInSite" that defaults to false. This means that people who want the pmd.xml file to be included in the site will have to configure that, when they upgrade the plugin to 3.0. I think that most people don't care if the pmd.xml file is included in the site or not. It's better that our plugins are consistent in their behavior. > maven-pmd-plugin should generate only one pmd.xml file > -- > > Key: MPMD-80 > URL: https://jira.codehaus.org/browse/MPMD-80 > Project: Maven 2.x PMD Plugin > Issue Type: Improvement > Components: PMD >Affects Versions: 2.3 >Reporter: Ulli Hafner >Priority: Minor > > Currently the task mvn pmd:pmd generates two identical pmd.xml report files: > one file is in target/pmd.xml, the other in target/site/pmd.xml. (findbugs > and checkstyle just generate one file in the target folder). > These two identical files hinder the processing by warning visualizations > tools (like the Hudson CI server pmd-plugin) that use these m2 generated > files as input. Normally, in Hudson one can just specify the file pattern > **/pmd.xml to obtain the available files to process. (Of course the user > might change the default pattern to **/target/pmd.xml, but it would be much > smarter if this would not be a requirement. And using **/target/pmd.xml as > default is also no possibility, since ant has no target folder...) > See: https://hudson.dev.java.net/issues/show_bug.cgi?id=1647 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-130) excludeRoot doesn't work in site build on multi-module projects
[
https://jira.codehaus.org/browse/MPMD-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315824#comment-315824
]
Dennis Lundberg commented on MPMD-130:
--
Where do you put your configuration, under or ?
Please provide a complete sample project.
> excludeRoot doesn't work in site build on multi-module projects
> ---
>
> Key: MPMD-130
> URL: https://jira.codehaus.org/browse/MPMD-130
> Project: Maven 2.x PMD Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Marcel Stör
>
> The parent POM of my multi-module setup says
>
> 1.6
>
> target/generated-sources
>
>
> If I run {{mvn pmd:cpd}} or {{mvn site}} directly on the module that actually
> has generated code the report is as expected. The files in
> {{target/generated-sources}} are ignored. Also, if I run {{mvn pmd:cpd}} at
> root level outside all the modules the report is fine.
> However, if I run {{mvn site}} at root level outside all the modules the
> excludeRoot is ignored.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-143) module site(s) created in the wrong place
[ https://jira.codehaus.org/browse/MPMD-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MPMD-143. Resolution: Not A Bug Plugins handle aggregated reports differently. The old way, which maven-pmd-plugin uses, has an aggregate parameter. The new way has two different reports - one aggregated and one non-aggregated. Hopefully we can converge all plugins so that they all work in the same way, but that will take some time... > module site(s) created in the wrong place > - > > Key: MPMD-143 > URL: https://jira.codehaus.org/browse/MPMD-143 > Project: Maven 2.x PMD Plugin > Issue Type: Bug > Components: CPD, PMD >Affects Versions: 2.6, 2.7 > Environment: Linux, Maven 2.2.1 >Reporter: Robin Vobruba > Attachments: TestProject.zip > > > having this project structure: > pom.xml[type=pom, defines the pmd plugin in the reporting section] > modules/part1/pom.xml[type=jar] > modules/part2/pom.xml[type=jar] > running "mvn site" on the parent project generates all reports on the parent > target/site/ folder (Project License, CheckStyle, FindBugs, ...), except PMD > and CPD, which get generated in the two modules target/site/ dirs, and thus > do not show up in the main report. > tested with maven PMD plugin versions 2.6 and 2.7. > if more info is needed, or testing, tell me please. > i attached a a zip file with a quite minimal test project. > The zip contains a folder TestProject with the above structure inside. try > running "mvn site" in folder TestProject, and have a loot at: > target/site/ > modules/part1/target/site/ > modules/part2/target/site/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315826#comment-315826
]
Lennart Jörelid commented on MSITE-669:
---
While the sample project is created only to illustrate the symptoms for this
issue, there are several quite legitimate reasons to not wanting the reactor
pom be the logical parent for the distribution. (Separate parent poms for
reactor poms not intended to be deployed/distributed and all other artifacts
intended to be deployed, for instance).
However, I suggest that we update the documentation for the maven-site-plugin,
to clarify that the {{site:stage}} goal assumes 3 things to work properly:
# The pom.xml of the topmost project in a multi-module build must define the
distributionManagement URL element (called "rootURL" hereafter). The rootURL
must be the *topmost* distributionManagement URL in the multi-module project,
implying that any distributionManagement URL defined within another project in
a multimodule build must start with the rootURL and append unique paths (to be
situated "below" the rootURL).
# All projects in multi-module builds must define unique distributionManagement
url elements, below/under the root distributionManagement URL in terms of URL
path.
# If the artifactId and module name (i.e. directory name) are not identical for
any project within a multi-module build, the distributionManagement URL element
must be defined in the pom.xml file in the project.
I would suggest adding these facts to the maven-site-plugin documentation, as
well as a small example holding a multimodule project containing at least one
occurrence of a project where artifactId and module name are not identical.
> site:stage creates incorrect structure when module paths contains sets of
> "../"
> ---
>
> Key: MSITE-669
> URL: https://jira.codehaus.org/browse/MSITE-669
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links, site:stage(-deploy)
>Affects Versions: 3.1, 3.2
>Reporter: Lennart Jörelid
>Assignee: Lukas Theussl
> Attachments: sample.zip
>
>
> Given the module definitions given below, the site:stage goal produces sets
> of maps relative to the staging directory - i.e. outside of the target
> directory.
> {code:xml}
>
> ../../validation/validation-api
> ../../validation/validation-aspect
> ../parent
>
> {code}
> The staged site should be fully included within the staging directory. It
> would appear that relativization of links for site:stage should take special
> links into consideration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-130) excludeRoot doesn't work in site build on multi-module projects
[
https://jira.codehaus.org/browse/MPMD-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315828#comment-315828
]
Marcel Stör commented on MPMD-130:
--
{quote}Please provide a complete sample project.{quote}
Sorry, I can't. We've since moved to Sonar and dumped PMD.
> excludeRoot doesn't work in site build on multi-module projects
> ---
>
> Key: MPMD-130
> URL: https://jira.codehaus.org/browse/MPMD-130
> Project: Maven 2.x PMD Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Marcel Stör
>
> The parent POM of my multi-module setup says
>
> 1.6
>
> target/generated-sources
>
>
> If I run {{mvn pmd:cpd}} or {{mvn site}} directly on the module that actually
> has generated code the report is as expected. The files in
> {{target/generated-sources}} are ignored. Also, if I run {{mvn pmd:cpd}} at
> root level outside all the modules the report is fine.
> However, if I run {{mvn site}} at root level outside all the modules the
> excludeRoot is ignored.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315829#comment-315829
]
Lukas Theussl commented on MSITE-669:
-
Some of these points are already buried in the docs:
http://maven.apache.org/plugins/maven-site-plugin/examples/multimodule.html#Staging_and_deploying
http://maven.apache.org/plugins/maven-site-plugin/faq.html#Use_of_url
I have added your points
([r1422896|http://svn.apache.org/viewvc?view=revision&revision=1422896]) and
fixed some wrong information in the FAQ above.
> site:stage creates incorrect structure when module paths contains sets of
> "../"
> ---
>
> Key: MSITE-669
> URL: https://jira.codehaus.org/browse/MSITE-669
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links, site:stage(-deploy)
>Affects Versions: 3.1, 3.2
>Reporter: Lennart Jörelid
>Assignee: Lukas Theussl
> Attachments: sample.zip
>
>
> Given the module definitions given below, the site:stage goal produces sets
> of maps relative to the staging directory - i.e. outside of the target
> directory.
> {code:xml}
>
> ../../validation/validation-api
> ../../validation/validation-aspect
> ../parent
>
> {code}
> The staged site should be fully included within the staging directory. It
> would appear that relativization of links for site:stage should take special
> links into consideration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315830#comment-315830
]
Lennart Jörelid commented on MSITE-669:
---
It seems that there are more pieces to the puzzle than the 3 items mentioned
above.
After applying these 3 site URL fixes to a small but real project
https://bitbucket.org/lennartj/nazgul_tools/
... the staged site still gets created outside of the target/staging directory;
for example the site of the validation-api is deployed within the root
directory of the validation api itself. Navigation is broken.
What other requirements are required by the maven-site-plugin to supply proper
staging?
> site:stage creates incorrect structure when module paths contains sets of
> "../"
> ---
>
> Key: MSITE-669
> URL: https://jira.codehaus.org/browse/MSITE-669
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links, site:stage(-deploy)
>Affects Versions: 3.1, 3.2
>Reporter: Lennart Jörelid
>Assignee: Lukas Theussl
> Attachments: sample.zip
>
>
> Given the module definitions given below, the site:stage goal produces sets
> of maps relative to the staging directory - i.e. outside of the target
> directory.
> {code:xml}
>
> ../../validation/validation-api
> ../../validation/validation-aspect
> ../parent
>
> {code}
> The staged site should be fully included within the staging directory. It
> would appear that relativization of links for site:stage should take special
> links into consideration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315830#comment-315830
]
Lennart Jörelid edited comment on MSITE-669 at 12/17/12 7:58 AM:
-
It seems that there are more pieces to the puzzle than the 3 items mentioned
above.
After applying these 3 site URL fixes to a small but real project
https://bitbucket.org/lennartj/nazgul_tools/
... the staged site still gets created outside of the target/staging directory;
for example the site of the validation-api is deployed within the root
directory of the validation api itself. Navigation is broken.
What other requirements are required by the maven-site-plugin to supply proper
staging?
Is there - for example - some requirement WRT the {{relativePath}} element of
the parent pom?
was (Author: l...@jguru.se):
It seems that there are more pieces to the puzzle than the 3 items
mentioned above.
After applying these 3 site URL fixes to a small but real project
https://bitbucket.org/lennartj/nazgul_tools/
... the staged site still gets created outside of the target/staging directory;
for example the site of the validation-api is deployed within the root
directory of the validation api itself. Navigation is broken.
What other requirements are required by the maven-site-plugin to supply proper
staging?
> site:stage creates incorrect structure when module paths contains sets of
> "../"
> ---
>
> Key: MSITE-669
> URL: https://jira.codehaus.org/browse/MSITE-669
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links, site:stage(-deploy)
>Affects Versions: 3.1, 3.2
>Reporter: Lennart Jörelid
>Assignee: Lukas Theussl
> Attachments: sample.zip
>
>
> Given the module definitions given below, the site:stage goal produces sets
> of maps relative to the staging directory - i.e. outside of the target
> directory.
> {code:xml}
>
> ../../validation/validation-api
> ../../validation/validation-aspect
> ../parent
>
> {code}
> The staged site should be fully included within the staging directory. It
> would appear that relativization of links for site:stage should take special
> links into consideration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315831#comment-315831
]
Lukas Theussl commented on MSITE-669:
-
There should be no requirement wrt the relativePath element (however, in
practice I am not so sure anymore...). One problem I see is that some of your
modules inherit from parents that are not related to the rest of the project.
Eg the codestyle module has no parent, therefore its site gets staged into the
current staging dir, ie into the same dir as the nazgul-tools-reactor if the
build is started from there. The same is true for eg
nazgul-tools-validation-api which inherits from nazgul-tools-parent which has
no parent, ie its site is not related to the reactor site. The relative path
between nazgul-tools-validation-api and nazgul-tools-parent is computed as
"../../" and this is appended to the base staging url of the reactor build
giving complete nonsense. I am rather confused by your project layout still but
IIUC this should be a problem specific to staging. Can you try to do a local
file deploy instead (ie indicate file:// urls as distMngmnt site urls and run
site:deploy). If this works it should also work when the site is deployed
remotely.
> site:stage creates incorrect structure when module paths contains sets of
> "../"
> ---
>
> Key: MSITE-669
> URL: https://jira.codehaus.org/browse/MSITE-669
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links, site:stage(-deploy)
>Affects Versions: 3.1, 3.2
>Reporter: Lennart Jörelid
>Assignee: Lukas Theussl
> Attachments: sample.zip
>
>
> Given the module definitions given below, the site:stage goal produces sets
> of maps relative to the staging directory - i.e. outside of the target
> directory.
> {code:xml}
>
> ../../validation/validation-api
> ../../validation/validation-aspect
> ../parent
>
> {code}
> The staged site should be fully included within the staging directory. It
> would appear that relativization of links for site:stage should take special
> links into consideration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-104) Verifier#assertFileNotPresent() fails when looking for an unwanted jar resource
[
https://jira.codehaus.org/browse/MSHARED-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed MSHARED-104.
--
Resolution: Fixed
Fix Version/s: maven-verifier-1.4
Assignee: Kristian Rosenvold
Fixed in r1421845
> Verifier#assertFileNotPresent() fails when looking for an unwanted jar
> resource
> ---
>
> Key: MSHARED-104
> URL: https://jira.codehaus.org/browse/MSHARED-104
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-verifier
>Affects Versions: maven-verifier-1.0, maven-verifier-1.2
>Reporter: Francis De Brabandere
>Assignee: Kristian Rosenvold
> Fix For: maven-verifier-1.4
>
>
> when using Verifier#assertFileNotPresent() to assert that a file is not
> present inside a jar, the assertion always fails.
> This is because looking for the resource throws a FileNotFoundException which
> is not catched at the correct place. The code that performs the actual test
> is never run. The exception should be catched and validated to the "wanted"
> parameter.
> This can be reproduced like this:
> // always fails even if the file is not present
> verifier.assertFileNotPresent("target/test.jar!/missing.xml");
> I suggest creating a unit test to test this case!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-178) Verifier#setDebug seems ineffective
[ https://jira.codehaus.org/browse/MSHARED-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MSHARED-178. -- Resolution: Fixed Fix Version/s: maven-verifier-1.4 Assignee: Kristian Rosenvold Fixed in r1421843 > Verifier#setDebug seems ineffective > --- > > Key: MSHARED-178 > URL: https://jira.codehaus.org/browse/MSHARED-178 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-verifier >Affects Versions: maven-verifier-1.2 >Reporter: Jerome Lacoste >Assignee: Kristian Rosenvold > Fix For: maven-verifier-1.4 > > > Looking at the Verifier code: > http://maven.apache.org/shared/maven-verifier/xref/index.html > it seems that this.debug is only used in the constructor > (http://maven.apache.org/shared/maven-verifier/xref/org/apache/maven/it/Verifier.html#130). > The setDebug() method > (http://maven.apache.org/shared/maven-verifier/xref/org/apache/maven/it/Verifier.html#2056) > will then be ineffective. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-268) Add ability to fine-control location of extracted resources
Kristian Rosenvold created MSHARED-268: -- Summary: Add ability to fine-control location of extracted resources Key: MSHARED-268 URL: https://jira.codehaus.org/browse/MSHARED-268 Project: Maven Shared Components Issue Type: New Feature Components: maven-verifier Affects Versions: maven-verifier-1.3 Reporter: Kristian Rosenvold The current version of maven-verifier always unpacks the same source to the same destination, which is really bad for thread safety -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-268) Add ability to fine-control location of extracted resources
[ https://jira.codehaus.org/browse/MSHARED-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MSHARED-268. -- Resolution: Fixed Fix Version/s: maven-verifier-1.4 Assignee: Kristian Rosenvold Fixed in r1416982 > Add ability to fine-control location of extracted resources > --- > > Key: MSHARED-268 > URL: https://jira.codehaus.org/browse/MSHARED-268 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-verifier >Affects Versions: maven-verifier-1.3 >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold > Fix For: maven-verifier-1.4 > > > The current version of maven-verifier always unpacks the same source to the > same destination, which is really bad for thread safety -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-648) NoClassDefFoundError upgrading to Maven Site Plugin 3.1
[
https://jira.codehaus.org/browse/MSITE-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315843#comment-315843
]
Guimiot Isabelle commented on MSITE-648:
I had exactly the same problem : I resolved it by deleting the
org/apache/maven/doxia directory from my local maven repository, then it worked
fine again !
> NoClassDefFoundError upgrading to Maven Site Plugin 3.1
> ---
>
> Key: MSITE-648
> URL: https://jira.codehaus.org/browse/MSITE-648
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Ian Brandt
> Attachments: build.log, MSITE-648.out
>
>
> When I update from 3.0 to 3.1 I get the error below. I've reproduced it on a
> couple projects, but here is a relatively simple POM that manifests the issue
> when updated:
> https://github.com/themadcreator/rabinfingerprint/blob/447cd065825b97e62a9b100f080ba217ba821de7/pom.xml
> {noformat}
> [INFO] --- maven-site-plugin:3.1:site (default-site) @ rabinfingerprint ---
> Aug 12, 2012 12:35:05 PM org.sonatype.guice.bean.reflect.Logs$JULSink warn
> WARNING: Error injecting:
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer
> java.lang.NoClassDefFoundError: org/apache/maven/doxia/logging/Log
> at java.lang.Class.getDeclaredConstructors0(Native Method)
> [...]
> Caused by: java.lang.ClassNotFoundException:
> org.apache.maven.doxia.logging.Log
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
> ... 89 more
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MANTTASKS-177) artifact:dependencies ignores settings-security.xml and sends password hash to repository
[
https://jira.codehaus.org/browse/MANTTASKS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Holger Reise updated MANTTASKS-177:
---
Attachment: decrypt.patch
patch file for decryption
> artifact:dependencies ignores settings-security.xml and sends password hash
> to repository
> -
>
> Key: MANTTASKS-177
> URL: https://jira.codehaus.org/browse/MANTTASKS-177
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: dependencies task
>Affects Versions: 2.1.0
> Environment: Mac OS X, Ant 1.7.1, Maven 2.2.1, maven-ant-tasks 2.1.0,
> Sonatype Nexus Open Source Edition 1.5.0
>Reporter: Ross Mellgren
> Attachments: decrypt.patch
>
>
> I have a mirror repository configured in .m2/settings.xml, and its
> entry uses an encrypted password in , using the master password set
> in .m2/settings-security.xml.
> I followed this guide:
> http://maven.apache.org/guides/mini/guide-encryption.html
> I get authentication errors every time i use
> {code:xml}
>
>
>
>
> paytronix-public
>
> https://greylock.corp.paytronix.com/nexus/content/groups/public
> *
>
>
>
>
> paytronix-public
> rmellgren
>
>
>
>
> {code}
> I switched to http and then used tcpdump to watch the request, then decoded
> the Authorization header. The {mumblemumble} password hash was sent not the
> decrypted password.
> Looking into maven-ant-tasks.jar, I see a META-INF/plexus/components.xml
> which does not include plexus-sec-dispatcher from maven-core. I tried
> spinning my own copy of maven-ant-tasks with the appropriate component for
> plexus-sec-dispatcher added, but it didn't work, so I think I'm out of my
> depth in the troubleshooting/rectification department.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MANTTASKS-177) artifact:dependencies ignores settings-security.xml and sends password hash to repository
[
https://jira.codehaus.org/browse/MANTTASKS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315845#comment-315845
]
Holger Reise edited comment on MANTTASKS-177 at 12/17/12 12:17 PM:
---
This patch did the trick for me
was (Author: hreise):
patch file for decryption
> artifact:dependencies ignores settings-security.xml and sends password hash
> to repository
> -
>
> Key: MANTTASKS-177
> URL: https://jira.codehaus.org/browse/MANTTASKS-177
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: dependencies task
>Affects Versions: 2.1.0
> Environment: Mac OS X, Ant 1.7.1, Maven 2.2.1, maven-ant-tasks 2.1.0,
> Sonatype Nexus Open Source Edition 1.5.0
>Reporter: Ross Mellgren
> Attachments: decrypt.patch
>
>
> I have a mirror repository configured in .m2/settings.xml, and its
> entry uses an encrypted password in , using the master password set
> in .m2/settings-security.xml.
> I followed this guide:
> http://maven.apache.org/guides/mini/guide-encryption.html
> I get authentication errors every time i use
> {code:xml}
>
>
>
>
> paytronix-public
>
> https://greylock.corp.paytronix.com/nexus/content/groups/public
> *
>
>
>
>
> paytronix-public
> rmellgren
>
>
>
>
> {code}
> I switched to http and then used tcpdump to watch the request, then decoded
> the Authorization header. The {mumblemumble} password hash was sent not the
> decrypted password.
> Looking into maven-ant-tasks.jar, I see a META-INF/plexus/components.xml
> which does not include plexus-sec-dispatcher from maven-core. I tried
> spinning my own copy of maven-ant-tasks with the appropriate component for
> plexus-sec-dispatcher added, but it didn't work, so I think I'm out of my
> depth in the troubleshooting/rectification department.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-933) forkMode onceperthread broken after fix for JUnit category filter with empty result
[
https://jira.codehaus.org/browse/SUREFIRE-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Gudian updated SUREFIRE-933:
Attachment: SUREFIRE-933-part2.patch
SUREFIRE-933-part1.patch
For the record: attached patch containing the content of pull-request 13
(SUREFIRE-933-part1.patch) and pull-request 15 (SUREFIRE-933-part2.patch)
> forkMode onceperthread broken after fix for JUnit category filter with empty
> result
> ---
>
> Key: SUREFIRE-933
> URL: https://jira.codehaus.org/browse/SUREFIRE-933
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.13
>Reporter: Andreas Gudian
>Assignee: Kristian Rosenvold
> Fix For: 2.13
>
> Attachments: SUREFIRE-933-part1.patch, SUREFIRE-933-part2.patch
>
>
> In forkMode {{onceperthread}} (reusable fork), the {{TestsToRun}} object will
> always be a {{LazyTestsToRun}} instance, which throws an excetpion if
> {{getLocatedClasses()}} is called. The fix for SUREFIRE-839 changed
> {{JUnitCoreWrapper}} and {{JUnitCoreProvider}} to call exactly that method.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-934) Remove getLocatedClasses() and size() from TestsToRun
[
https://jira.codehaus.org/browse/SUREFIRE-934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Gudian updated SUREFIRE-934:
Attachment: SUREFIRE-934.patch
For the record: attached the patch contained in pull-request 14.
> Remove getLocatedClasses() and size() from TestsToRun
> -
>
> Key: SUREFIRE-934
> URL: https://jira.codehaus.org/browse/SUREFIRE-934
> Project: Maven Surefire
> Issue Type: Task
> Components: process forking
>Affects Versions: 2.13
>Reporter: Andreas Gudian
>Assignee: Kristian Rosenvold
>Priority: Minor
> Fix For: 2.13
>
> Attachments: SUREFIRE-934.patch
>
>
> In order to avoid any further confusion with
> {{TestsToRun.getLocatedClasses()}} and {{TestsToRun.size()}} (as in
> SUREFIRE-933), I propose to remove these methods completely.
> Basically, these methods are used in the TestNG provider at some limited
> places, and in {{DefaultRunOrderCalculator}} during the scan for tests (in
> the main surefire process).
> If you have any objections, please close this issue. Otherwise, I will just
> do it and send a pull request.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-751) Support parallel/fork mode similar to http://maven-junit-plugin.kenai.com/
[ https://jira.codehaus.org/browse/SUREFIRE-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Gudian updated SUREFIRE-751: Attachment: SUREFIRE-751-part2.patch SUREFIRE-751-part1.patch For the record: attached the content of the two pull requests that contained the original patch. > Support parallel/fork mode similar to http://maven-junit-plugin.kenai.com/ > -- > > Key: SUREFIRE-751 > URL: https://jira.codehaus.org/browse/SUREFIRE-751 > Project: Maven Surefire > Issue Type: New Feature > Components: process forking >Affects Versions: 2.9 >Reporter: Stephen Connolly >Assignee: Kristian Rosenvold > Fix For: 2.13 > > Attachments: SUREFIRE-751-part1.patch, SUREFIRE-751-part2.patch > > > The current parallel execution spawns one thread _per_class_ > When there is a large disparity between the number of tests in different > classes, this can result in a longer execution time. This can often happen in > GUI testing, where a couple of classes will contain a lot of long running > (but low cpu) test cases, and the remaining classes run fast. > See http://maven-junit-plugin.kenai.com/ for an attempt at solving this -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEPLOY-99) deploy:deploy-file over rights maven-metadata.xml
[
https://jira.codehaus.org/browse/MDEPLOY-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MDEPLOY-99:
--
Description:
Using {{deploy:deploy-file}} to add multiple version of an artifact causes the
artifactId {{maven-metadata.xml}} file to be recreated new and the old contents
to be removed. Once done I am left with contents like this:
{code:xml}
com.pervasive.component
artifact-distribution
4.0.2.11
4.0.2.11
20090401013925
{code}
This is using Maven 2.1.0 and maven-deploy-plugin 2.4.
was:
Using deploy:deploy-file to add multiple version of an artifact causes the
artifactId maven-metadata.xml file to be recreated new and the old contents to
be removed. Once done I am left with contents like this:
com.pervasive.component
artifact-distribution
4.0.2.11
4.0.2.11
20090401013925
This is using Maven 2.1.0 and maven-deploy-plugin 2.4.
Environment:
Windows XP
Maven 2.1.0
was:Windows XP
> deploy:deploy-file over rights maven-metadata.xml
> -
>
> Key: MDEPLOY-99
> URL: https://jira.codehaus.org/browse/MDEPLOY-99
> Project: Maven 2.x and 3.x Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy-file
>Affects Versions: 2.4
> Environment: Windows XP
> Maven 2.1.0
>Reporter: Jim McCaskey
> Labels: scrub-review-started
>
> Using {{deploy:deploy-file}} to add multiple version of an artifact causes
> the artifactId {{maven-metadata.xml}} file to be recreated new and the old
> contents to be removed. Once done I am left with contents like this:
> {code:xml}
>
> com.pervasive.component
> artifact-distribution
> 4.0.2.11
>
>
> 4.0.2.11
>
> 20090401013925
>
>
> {code}
> This is using Maven 2.1.0 and maven-deploy-plugin 2.4.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-187) dependency:copy fails when invoked from m2e with workspace resolution enabled, or more generally when copying within reactor for phases earlier than package
[ https://jira.codehaus.org/browse/MDEP-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305208#comment-305208 ] Herve Boutemy edited comment on MDEP-187 at 12/17/12 8:51 PM: -- copy problem looks a lot like unpack problem, but has a major difference: when unpack finds a directory, copying it ressembles a lot to unpacking packaged artifact (if no classifier and nothing generated during packaging) but if copy finds a directory, what is it expected to do? copy the directory (even if expected result is a file)? create a zip file with the directory content? create a jar file (what to do with the Manifest?)? fail? ignore with warning? this seems like there is no solution other than require to package first, or we'll get an approximation that can be more problematic than a clear failure was (Author: hboutemy): copy problem looks a lot like unpack problem, but has a major difference: when unpack finds a directory, copying it ressembles a lot to unpacking packaged artifact (if no classifier and nothing generated during packaging) but if copy finds a directory, what is it expected to do? copy the directory (even if expected result is a file)? create a zip file with the directory content? fail? ignore with warning? > dependency:copy fails when invoked from m2e with workspace resolution > enabled, or more generally when copying within reactor for phases earlier > than package > > > Key: MDEP-187 > URL: https://jira.codehaus.org/browse/MDEP-187 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: copy, copy-dependencies >Affects Versions: 2.1 >Reporter: Igor Fedorenko > Attachments: MDEP-187b.diff, MDEP-187c.diff, MDEP-187.diff > > > m2e resolves workspace artifacts to their output folders but dependency:copy > expects all artifacts to be files. I will provide trivial patch shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-187) dependency:copy fails when invoked from m2e with workspace resolution enabled, or more generally when copying within reactor for phases earlier than package
[ https://jira.codehaus.org/browse/MDEP-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305211#comment-305211 ] Herve Boutemy edited comment on MDEP-187 at 12/17/12 8:52 PM: -- error message improved in [r1368246|http://svn.apache.org/viewvc?rev=1368246&view=rev] this doesn't fix the problem (which cannot be fixed IMHO) but at least makes it easier to track notice that another corner case to take care is when the dependency to copy has a classifier: we can't even imagine the content before the artifact has been packaged was (Author: hboutemy): error message improved in [r1368246|http://svn.apache.org/viewvc?rev=1368246&view=rev] this doesn't fix the problem but at least makes it easier to track notice that another corner case to take care is when the dependency to copy has a classifier: we can't imagine the content before the artifact has been packaged > dependency:copy fails when invoked from m2e with workspace resolution > enabled, or more generally when copying within reactor for phases earlier > than package > > > Key: MDEP-187 > URL: https://jira.codehaus.org/browse/MDEP-187 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: copy, copy-dependencies >Affects Versions: 2.1 >Reporter: Igor Fedorenko > Attachments: MDEP-187b.diff, MDEP-187c.diff, MDEP-187.diff > > > m2e resolves workspace artifacts to their output folders but dependency:copy > expects all artifacts to be files. I will provide trivial patch shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315858#comment-315858
]
Lennart Jörelid commented on MSITE-669:
---
I don't understand why a project which has a defined siteURL, located below the
rootURL (defined as the distributionManagement URL element of the topmost
project in the reactor) would need to consult its parent settings to define its
*staging directory*. That implies the 3 rules for {{site:stage}} work defined
above do not fully describe the assumptions used by the maven-site-plugin and
its {{site:stage}} goal, but that we seem to have two additional requirements:
# The {{site:stage}} goal assumes that all projects within the reactor use the
same parent.
# The parent project of a site:stage run must be the reactor root.
These assumptions feel rather constraining, to be honest.
My [obviously incorrect] conceptual model is that the parent project would only
be consulted to:
# Inherit/merge pom settings. (If no parent is defined, simply use what is
defined within the project itself.)
# Inherit/merge site.xml settings (If no parent is defined, simply use what is
defined within the subproject itself.)
# Read the distributionManagement URL setting within the parent pom in order to
create the link for
> site:stage creates incorrect structure when module paths contains sets of
> "../"
> ---
>
> Key: MSITE-669
> URL: https://jira.codehaus.org/browse/MSITE-669
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links, site:stage(-deploy)
>Affects Versions: 3.1, 3.2
>Reporter: Lennart Jörelid
>Assignee: Lukas Theussl
> Attachments: sample.zip
>
>
> Given the module definitions given below, the site:stage goal produces sets
> of maps relative to the staging directory - i.e. outside of the target
> directory.
> {code:xml}
>
> ../../validation/validation-api
> ../../validation/validation-aspect
> ../parent
>
> {code}
> The staged site should be fully included within the staging directory. It
> would appear that relativization of links for site:stage should take special
> links into consideration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lennart Jörelid updated MSITE-669:
--
Attachment: nazgul_tools_reactor_structure.png
Structure of desired staged site.
White pom-type reactor projects only define modules and sites. Such projects do
not produce anything worth deploying - other than their part within the
site:stage.
Yellow jar/bundle-type projects define a single deployable artifact, as well as
documentation in the form of a maven site. These project artifacts would be
deployed to a repo in a normal manner as well as part of a compound/staged site.
> site:stage creates incorrect structure when module paths contains sets of
> "../"
> ---
>
> Key: MSITE-669
> URL: https://jira.codehaus.org/browse/MSITE-669
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links, site:stage(-deploy)
>Affects Versions: 3.1, 3.2
>Reporter: Lennart Jörelid
>Assignee: Lukas Theussl
> Attachments: nazgul_tools_reactor_structure.png, sample.zip
>
>
> Given the module definitions given below, the site:stage goal produces sets
> of maps relative to the staging directory - i.e. outside of the target
> directory.
> {code:xml}
>
> ../../validation/validation-api
> ../../validation/validation-aspect
> ../parent
>
> {code}
> The staged site should be fully included within the staging directory. It
> would appear that relativization of links for site:stage should take special
> links into consideration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lennart Jörelid updated MSITE-669:
--
Attachment: nazgul_tools_project_dependencies.png
> site:stage creates incorrect structure when module paths contains sets of
> "../"
> ---
>
> Key: MSITE-669
> URL: https://jira.codehaus.org/browse/MSITE-669
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links, site:stage(-deploy)
>Affects Versions: 3.1, 3.2
>Reporter: Lennart Jörelid
>Assignee: Lukas Theussl
> Attachments: nazgul_tools_project_dependencies.png,
> nazgul_tools_reactor_structure.png, sample.zip
>
>
> Given the module definitions given below, the site:stage goal produces sets
> of maps relative to the staging directory - i.e. outside of the target
> directory.
> {code:xml}
>
> ../../validation/validation-api
> ../../validation/validation-aspect
> ../parent
>
> {code}
> The staged site should be fully included within the staging directory. It
> would appear that relativization of links for site:stage should take special
> links into consideration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lennart Jörelid updated MSITE-669:
--
Attachment: nazgul_tools_project_dependencies.png
Correct version
> site:stage creates incorrect structure when module paths contains sets of
> "../"
> ---
>
> Key: MSITE-669
> URL: https://jira.codehaus.org/browse/MSITE-669
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links, site:stage(-deploy)
>Affects Versions: 3.1, 3.2
>Reporter: Lennart Jörelid
>Assignee: Lukas Theussl
> Attachments: nazgul_tools_project_dependencies.png,
> nazgul_tools_project_dependencies.png, nazgul_tools_reactor_structure.png,
> sample.zip
>
>
> Given the module definitions given below, the site:stage goal produces sets
> of maps relative to the staging directory - i.e. outside of the target
> directory.
> {code:xml}
>
> ../../validation/validation-api
> ../../validation/validation-aspect
> ../parent
>
> {code}
> The staged site should be fully included within the staging directory. It
> would appear that relativization of links for site:stage should take special
> links into consideration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315861#comment-315861
]
Lennart Jörelid commented on MSITE-669:
---
I attached two images to clarify
# The reactor build structure (module definitions). This is how I want the
navigation within the site:stage to work (and - up until recently - believed it
should work).
#* Illustrated by image _nazgul_tools_reactor_structure_
#* White pom-type reactor projects only define modules and sites, thereby
glueing together the build reactor. Such projects do not produce anything worth
deploying - other than potential documentation which should be part of the
{{site:stage}}.
#* Yellow jar/bundle-type projects define a single deployable artifact, as well
as documentation in the form of a maven site. These project artifacts would be
deployed to a repo in a normal manner as well as part of a compound/staged site.
# The project dependencies including inclusions.
#* Illustrated by image _nazgul_tools_project_dependencies_. [Please remove the
earlier/incorrect of the two versions].
#* The reactor structure briefly explained (to alleviate any confusion):
#*# The codestyle project contains rules for checkstyle, enforcer, PMD etc.
This is essentially the implementation of the developer guidelines.
#*# The tools-parent project defines the build reactor, including dependency
management settings. The plugins use configuration/rules from the codestyle
project, implying that the tools-parent project include codestyle as a
dependency. Therefore, tools-parent is built after codestyle.
#*# The validation-api defines the API of a globally available aspect. It
defines the tools-parent as parent project, to use the build cycle/codestyle
rules defined within tools-parent.
#*# The validation-aspect defines the globally available aspect implementation,
depending on the validation-api and using the tools-parent as parent project
(to use the build cycle/codestyle rules defined within tools-parent).
#*# The parent project configures AspectJ to use the aspect implementation from
validation-aspect. This makes the validation-aspect globally available to all
projects using the parent project as ... well ... parent.
Comments:
# It seems too invasive to require parent poms (tools-parent, parent) to define
modules just to acquire a staged site with working navigation. These projects
*should* be leaves, because they may be used as parents by poms outside of the
nazgul_tools reactor.
# It is practical to make all of the projects illustrated above be part of a
single reactor, since they are released as a unit - and should be documented as
a unit. I suggest that the {{site:stage}} should support this scenario.
# The structure I would expect from the {{site:stage}} command for the
nazgul_tools reactor, which would match the reactor closely. (In terms of
links/navigation).
> site:stage creates incorrect structure when module paths contains sets of
> "../"
> ---
>
> Key: MSITE-669
> URL: https://jira.codehaus.org/browse/MSITE-669
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links, site:stage(-deploy)
>Affects Versions: 3.1, 3.2
>Reporter: Lennart Jörelid
>Assignee: Lukas Theussl
> Attachments: nazgul_tools_project_dependencies.png,
> nazgul_tools_project_dependencies.png, nazgul_tools_reactor_structure.png,
> sample.zip
>
>
> Given the module definitions given below, the site:stage goal produces sets
> of maps relative to the staging directory - i.e. outside of the target
> directory.
> {code:xml}
>
> ../../validation/validation-api
> ../../validation/validation-aspect
> ../parent
>
> {code}
> The staged site should be fully included within the staging directory. It
> would appear that relativization of links for site:stage should take special
> links into consideration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315859#comment-315859
]
Lennart Jörelid edited comment on MSITE-669 at 12/17/12 10:38 PM:
--
(Comment moved)
was (Author: l...@jguru.se):
Structure of desired staged site.
White pom-type reactor projects only define modules and sites. Such projects do
not produce anything worth deploying - other than their part within the
site:stage.
Yellow jar/bundle-type projects define a single deployable artifact, as well as
documentation in the form of a maven site. These project artifacts would be
deployed to a repo in a normal manner as well as part of a compound/staged site.
> site:stage creates incorrect structure when module paths contains sets of
> "../"
> ---
>
> Key: MSITE-669
> URL: https://jira.codehaus.org/browse/MSITE-669
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links, site:stage(-deploy)
>Affects Versions: 3.1, 3.2
>Reporter: Lennart Jörelid
>Assignee: Lukas Theussl
> Attachments: nazgul_tools_project_dependencies.png,
> nazgul_tools_project_dependencies.png, nazgul_tools_reactor_structure.png,
> sample.zip
>
>
> Given the module definitions given below, the site:stage goal produces sets
> of maps relative to the staging directory - i.e. outside of the target
> directory.
> {code:xml}
>
> ../../validation/validation-api
> ../../validation/validation-aspect
> ../parent
>
> {code}
> The staged site should be fully included within the staging directory. It
> would appear that relativization of links for site:stage should take special
> links into consideration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315860#comment-315860
]
Lennart Jörelid edited comment on MSITE-669 at 12/17/12 10:38 PM:
--
Uploaded correct image version of the reactor structure.
was (Author: l...@jguru.se):
Correct version
> site:stage creates incorrect structure when module paths contains sets of
> "../"
> ---
>
> Key: MSITE-669
> URL: https://jira.codehaus.org/browse/MSITE-669
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links, site:stage(-deploy)
>Affects Versions: 3.1, 3.2
>Reporter: Lennart Jörelid
>Assignee: Lukas Theussl
> Attachments: nazgul_tools_project_dependencies.png,
> nazgul_tools_project_dependencies.png, nazgul_tools_reactor_structure.png,
> sample.zip
>
>
> Given the module definitions given below, the site:stage goal produces sets
> of maps relative to the staging directory - i.e. outside of the target
> directory.
> {code:xml}
>
> ../../validation/validation-api
> ../../validation/validation-aspect
> ../parent
>
> {code}
> The staged site should be fully included within the staging directory. It
> would appear that relativization of links for site:stage should take special
> links into consideration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315858#comment-315858
]
Lennart Jörelid edited comment on MSITE-669 at 12/17/12 10:38 PM:
--
I don't understand why a project which has a defined siteURL, located below the
rootURL (defined as the distributionManagement URL element of the topmost
project in the reactor) would need to consult its parent settings to define its
*staging directory*. That implies the 3 rules for {{site:stage}} work defined
above do not fully describe the assumptions used by the maven-site-plugin and
its {{site:stage}} goal, but that we seem to have two additional requirements:
# The {{site:stage}} goal assumes that all projects within the reactor use the
same parent.
# The parent project of a site:stage run must be the reactor root.
These assumptions feel rather constraining, to be honest.
My [obviously incorrect] conceptual model is/was that the parent project would
only be consulted to:
# Inherit/merge pom settings. (If no parent is defined, simply use what is
defined within the project itself.)
# Inherit/merge site.xml settings (If no parent is defined, simply use what is
defined within the subproject itself.)
# Read the distributionManagement URL setting within the parent pom in order to
create the link for
was (Author: l...@jguru.se):
I don't understand why a project which has a defined siteURL, located below
the rootURL (defined as the distributionManagement URL element of the topmost
project in the reactor) would need to consult its parent settings to define its
*staging directory*. That implies the 3 rules for {{site:stage}} work defined
above do not fully describe the assumptions used by the maven-site-plugin and
its {{site:stage}} goal, but that we seem to have two additional requirements:
# The {{site:stage}} goal assumes that all projects within the reactor use the
same parent.
# The parent project of a site:stage run must be the reactor root.
These assumptions feel rather constraining, to be honest.
My [obviously incorrect] conceptual model is that the parent project would only
be consulted to:
# Inherit/merge pom settings. (If no parent is defined, simply use what is
defined within the project itself.)
# Inherit/merge site.xml settings (If no parent is defined, simply use what is
defined within the subproject itself.)
# Read the distributionManagement URL setting within the parent pom in order to
create the link for
> site:stage creates incorrect structure when module paths contains sets of
> "../"
> ---
>
> Key: MSITE-669
> URL: https://jira.codehaus.org/browse/MSITE-669
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links, site:stage(-deploy)
>Affects Versions: 3.1, 3.2
>Reporter: Lennart Jörelid
>Assignee: Lukas Theussl
> Attachments: nazgul_tools_project_dependencies.png,
> nazgul_tools_project_dependencies.png, nazgul_tools_reactor_structure.png,
> sample.zip
>
>
> Given the module definitions given below, the site:stage goal produces sets
> of maps relative to the staging directory - i.e. outside of the target
> directory.
> {code:xml}
>
> ../../validation/validation-api
> ../../validation/validation-aspect
> ../parent
>
> {code}
> The staged site should be fully included within the staging directory. It
> would appear that relativization of links for site:stage should take special
> links into consideration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315858#comment-315858
]
Lennart Jörelid edited comment on MSITE-669 at 12/17/12 10:42 PM:
--
I don't understand why a project which has a defined siteURL, located below the
rootURL (defined as the distributionManagement URL element of the topmost
project in the reactor) would need to consult its parent settings to define its
*staging directory*. That implies the 3 rules for {{site:stage}} work defined
above do not fully describe the assumptions used by the maven-site-plugin and
its {{site:stage}} goal, but that we seem to have two additional requirements:
# The {{site:stage}} goal assumes that all projects within the reactor use the
same parent.
# The parent project of a site:stage run must be the reactor root.
These assumptions feel rather constraining, to be honest.
My [obviously incorrect] conceptual model is/was that the parent project would
only be consulted to:
# Inherit/merge pom settings. (If no parent is defined, simply use what is
defined within the project itself.)
# Inherit/merge site.xml settings (If no parent is defined, simply use what is
defined within the subproject itself.)
# Read the distributionManagement URL setting within the parent pom in order to
create the link for
I would suggest that we describe these current requirements/assumptions within
the documentation for {{site:stage}}, and implement a change to make
{{site:stage}} yield a navigation structure matching the reactor's. In the case
of the nazgul_tools reactor, its build order structure is illustrated in an
attached image.
was (Author: l...@jguru.se):
I don't understand why a project which has a defined siteURL, located below
the rootURL (defined as the distributionManagement URL element of the topmost
project in the reactor) would need to consult its parent settings to define its
*staging directory*. That implies the 3 rules for {{site:stage}} work defined
above do not fully describe the assumptions used by the maven-site-plugin and
its {{site:stage}} goal, but that we seem to have two additional requirements:
# The {{site:stage}} goal assumes that all projects within the reactor use the
same parent.
# The parent project of a site:stage run must be the reactor root.
These assumptions feel rather constraining, to be honest.
My [obviously incorrect] conceptual model is/was that the parent project would
only be consulted to:
# Inherit/merge pom settings. (If no parent is defined, simply use what is
defined within the project itself.)
# Inherit/merge site.xml settings (If no parent is defined, simply use what is
defined within the subproject itself.)
# Read the distributionManagement URL setting within the parent pom in order to
create the link for
> site:stage creates incorrect structure when module paths contains sets of
> "../"
> ---
>
> Key: MSITE-669
> URL: https://jira.codehaus.org/browse/MSITE-669
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links, site:stage(-deploy)
>Affects Versions: 3.1, 3.2
>Reporter: Lennart Jörelid
>Assignee: Lukas Theussl
> Attachments: nazgul_tools_project_dependencies.png,
> nazgul_tools_project_dependencies.png, nazgul_tools_reactor_structure.png,
> sample.zip
>
>
> Given the module definitions given below, the site:stage goal produces sets
> of maps relative to the staging directory - i.e. outside of the target
> directory.
> {code:xml}
>
> ../../validation/validation-api
> ../../validation/validation-aspect
> ../parent
>
> {code}
> The staged site should be fully included within the staging directory. It
> would appear that relativization of links for site:stage should take special
> links into consideration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315861#comment-315861
]
Lennart Jörelid edited comment on MSITE-669 at 12/17/12 10:43 PM:
--
I attached two images to clarify
# The reactor build structure (module definitions). This is how I want the
navigation within the site:stage to work (and - up until recently - believed it
should work).
#* Illustrated by image _nazgul_tools_reactor_structure_
#* White pom-type reactor projects only define modules and sites, thereby
glueing together the build reactor. Such projects do not produce anything worth
deploying - other than potential documentation which should be part of the
{{site:stage}}.
#* Yellow jar/bundle-type projects define a single deployable artifact, as well
as documentation in the form of a maven site. These project artifacts would be
deployed to a repo in a normal manner as well as part of a compound/staged site.
# The project dependencies including inclusions.
#* Illustrated by image _nazgul_tools_project_dependencies_. [Please remove the
earlier/incorrect of the two versions, as I cannot due to lacking privileges].
#* The reactor structure briefly explained (to alleviate any confusion):
#*# The codestyle project contains rules for checkstyle, enforcer, PMD etc.
This is essentially the implementation of the developer guidelines.
#*# The tools-parent project defines the build reactor, including dependency
management settings. The plugins use configuration/rules from the codestyle
project, implying that the tools-parent project include codestyle as a
dependency. Therefore, tools-parent is built after codestyle.
#*# The validation-api defines the API of a globally available aspect. It
defines the tools-parent as parent project, to use the build cycle/codestyle
rules defined within tools-parent.
#*# The validation-aspect defines the globally available aspect implementation,
depending on the validation-api and using the tools-parent as parent project
(to use the build cycle/codestyle rules defined within tools-parent).
#*# The parent project configures AspectJ to use the aspect implementation from
validation-aspect. This makes the validation-aspect globally available to all
projects using the parent project as ... well ... parent.
Comments:
# It seems too invasive to require parent poms (tools-parent, parent) to define
modules just to acquire a staged site with working navigation. These projects
*should* be leaves, because they may be used as parents by poms outside of the
nazgul_tools reactor.
# It is practical to make all of the projects illustrated above be part of a
single reactor, since they are released as a unit - and should be documented as
a unit. I suggest that the {{site:stage}} should support this scenario.
# The structure I would expect from the {{site:stage}} command for the
nazgul_tools reactor, which would match the reactor closely. (In terms of
links/navigation).
was (Author: l...@jguru.se):
I attached two images to clarify
# The reactor build structure (module definitions). This is how I want the
navigation within the site:stage to work (and - up until recently - believed it
should work).
#* Illustrated by image _nazgul_tools_reactor_structure_
#* White pom-type reactor projects only define modules and sites, thereby
glueing together the build reactor. Such projects do not produce anything worth
deploying - other than potential documentation which should be part of the
{{site:stage}}.
#* Yellow jar/bundle-type projects define a single deployable artifact, as well
as documentation in the form of a maven site. These project artifacts would be
deployed to a repo in a normal manner as well as part of a compound/staged site.
# The project dependencies including inclusions.
#* Illustrated by image _nazgul_tools_project_dependencies_. [Please remove the
earlier/incorrect of the two versions].
#* The reactor structure briefly explained (to alleviate any confusion):
#*# The codestyle project contains rules for checkstyle, enforcer, PMD etc.
This is essentially the implementation of the developer guidelines.
#*# The tools-parent project defines the build reactor, including dependency
management settings. The plugins use configuration/rules from the codestyle
project, implying that the tools-parent project include codestyle as a
dependency. Therefore, tools-parent is built after codestyle.
#*# The validation-api defines the API of a globally available aspect. It
defines the tools-parent as parent project, to use the build cycle/codestyle
rules defined within tools-parent.
#*# The validation-aspect defines the globally available aspect implementation,
depending on the validation-api and using the tools-parent as parent project
(to use the build cycle/codestyle rules defined within tools-parent).
#*# The parent projec
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315861#comment-315861
]
Lennart Jörelid edited comment on MSITE-669 at 12/17/12 10:45 PM:
--
I attached two images to clarify
# The reactor build structure (module definitions). This is how I want the
navigation within the site:stage to work (and - up until recently - believed it
should work).
#* Illustrated by image _nazgul_tools_reactor_structure_
#* White pom-type reactor projects only define modules and sites, thereby
glueing together the build reactor. Such projects do not produce anything worth
deploying - other than potential documentation which should be part of the
{{site:stage}}.
#* Yellow jar/bundle-type projects define a single deployable artifact, as well
as documentation in the form of a maven site. These project artifacts would be
deployed to a repo in a normal manner as well as part of a compound/staged site.
# The project dependencies including inclusions.
#* Illustrated by image _nazgul_tools_project_dependencies_. [Please remove the
earlier/incorrect of the two versions, as I cannot due to lacking privileges].
#* The reactor structure/projects briefly explained (to alleviate any
confusion):
#*# *Codestyle* := contains rules for checkstyle, enforcer, PMD etc. This is
essentially the implementation of the developer guidelines.
#*# *Tools-parent* := defines the build reactor, including dependency
management settings. The plugins use configuration/rules from the codestyle
project, implying that the tools-parent project include codestyle as a
dependency. Therefore, tools-parent is built after codestyle.
#*# *Validation-api* := defines the API of a globally available aspect. It
defines the tools-parent as parent project, to use the build cycle/codestyle
rules defined within tools-parent.
#*# *Validation-aspect* := defines the globally available aspect
implementation, depending on the validation-api and using the tools-parent as
parent project (to use the build cycle/codestyle rules defined within
tools-parent).
#*# *Parent* := configures AspectJ to use the aspect implementation from
validation-aspect. This makes the validation-aspect globally available to all
projects using the parent project as ... well ... parent.
Comments:
# It seems too invasive to require parent poms (tools-parent, parent) to define
modules just to acquire a staged site with working navigation. These projects
*should* be leaves, because they may be used as parents by poms outside of the
nazgul_tools reactor.
# It is practical to make all of the projects illustrated above be part of a
single reactor, since they are released as a unit - and should be documented as
a unit. I suggest that the {{site:stage}} should support this scenario.
# The structure I would expect from the {{site:stage}} command for the
nazgul_tools reactor, which would match the reactor closely. (In terms of
links/navigation).
was (Author: l...@jguru.se):
I attached two images to clarify
# The reactor build structure (module definitions). This is how I want the
navigation within the site:stage to work (and - up until recently - believed it
should work).
#* Illustrated by image _nazgul_tools_reactor_structure_
#* White pom-type reactor projects only define modules and sites, thereby
glueing together the build reactor. Such projects do not produce anything worth
deploying - other than potential documentation which should be part of the
{{site:stage}}.
#* Yellow jar/bundle-type projects define a single deployable artifact, as well
as documentation in the form of a maven site. These project artifacts would be
deployed to a repo in a normal manner as well as part of a compound/staged site.
# The project dependencies including inclusions.
#* Illustrated by image _nazgul_tools_project_dependencies_. [Please remove the
earlier/incorrect of the two versions, as I cannot due to lacking privileges].
#* The reactor structure briefly explained (to alleviate any confusion):
#*# The codestyle project contains rules for checkstyle, enforcer, PMD etc.
This is essentially the implementation of the developer guidelines.
#*# The tools-parent project defines the build reactor, including dependency
management settings. The plugins use configuration/rules from the codestyle
project, implying that the tools-parent project include codestyle as a
dependency. Therefore, tools-parent is built after codestyle.
#*# The validation-api defines the API of a globally available aspect. It
defines the tools-parent as parent project, to use the build cycle/codestyle
rules defined within tools-parent.
#*# The validation-aspect defines the globally available aspect implementation,
depending on the validation-api and using the tools-parent as parent project
(to use the build cycle/codestyle rules defined within tools
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315861#comment-315861
]
Lennart Jörelid edited comment on MSITE-669 at 12/18/12 12:37 AM:
--
I attached two images to clarify
# The reactor build structure (module definitions). This is how I believe the
navigation within the site:stage should work (and - until recently - the way I
believed it *did* work).
#* Illustrated in image _nazgul_tools_reactor_structure_
#* White pom-type reactor projects only define modules and sites, thereby
glueing together the build reactor. Such projects do not produce anything worth
deploying - other than potential documentation which should be part of the
{{site:stage}}.
#* Yellow jar/bundle-type projects define a single deployable artifact, as well
as documentation in the form of a maven site. These project artifacts would be
deployed to a repo in a normal manner as well as part of a compound/staged site.
# The project dependencies including inclusions.
#* Illustrated by image _nazgul_tools_project_dependencies_. [Please remove the
earlier/incorrect of the two versions, as I cannot due to lacking privileges].
#* The reactor structure/projects briefly explained (to alleviate any
confusion):
#*# *Codestyle* := contains rules for checkstyle, enforcer, PMD etc. This is
essentially the implementation of the developer guidelines.
#*# *Tools-parent* := defines the build reactor, including dependency
management settings. The plugins use configuration/rules from the codestyle
project, implying that the tools-parent project include codestyle as a
dependency. Therefore, tools-parent is built after codestyle.
#*# *Validation-api* := defines the API of a globally available aspect. It
defines the tools-parent as parent project, to use the build cycle/codestyle
rules defined within tools-parent.
#*# *Validation-aspect* := defines the globally available aspect
implementation, depending on the validation-api and using the tools-parent as
parent project (to use the build cycle/codestyle rules defined within
tools-parent).
#*# *Parent* := configures AspectJ to use the aspect implementation from
validation-aspect. This makes the validation-aspect globally available to all
projects using the parent project as ... well ... parent.
Comments:
# It seems too invasive to require parent poms (i.e. tools-parent, parent) to
define modules just to acquire a staged site with working navigation. These
projects *should* be leaves, because they may be used as parents by poms
outside of the nazgul_tools reactor.
# It is practical to make all of the projects illustrated above be part of a
single reactor, since they are released as a unit - and should be documented as
a unit. I suggest that the {{site:stage}} should support this scenario.
# The structure I would expect from the {{site:stage}} command for the
nazgul_tools reactor, would match the reactor closely in terms of
links/navigation. The desired/expected structure of the
{{site:stage}}-generated site is identical to the one illustrated in the image
_nazgul_tools_reactor_structure_ above.
was (Author: l...@jguru.se):
I attached two images to clarify
# The reactor build structure (module definitions). This is how I want the
navigation within the site:stage to work (and - up until recently - believed it
should work).
#* Illustrated by image _nazgul_tools_reactor_structure_
#* White pom-type reactor projects only define modules and sites, thereby
glueing together the build reactor. Such projects do not produce anything worth
deploying - other than potential documentation which should be part of the
{{site:stage}}.
#* Yellow jar/bundle-type projects define a single deployable artifact, as well
as documentation in the form of a maven site. These project artifacts would be
deployed to a repo in a normal manner as well as part of a compound/staged site.
# The project dependencies including inclusions.
#* Illustrated by image _nazgul_tools_project_dependencies_. [Please remove the
earlier/incorrect of the two versions, as I cannot due to lacking privileges].
#* The reactor structure/projects briefly explained (to alleviate any
confusion):
#*# *Codestyle* := contains rules for checkstyle, enforcer, PMD etc. This is
essentially the implementation of the developer guidelines.
#*# *Tools-parent* := defines the build reactor, including dependency
management settings. The plugins use configuration/rules from the codestyle
project, implying that the tools-parent project include codestyle as a
dependency. Therefore, tools-parent is built after codestyle.
#*# *Validation-api* := defines the API of a globally available aspect. It
defines the tools-parent as parent project, to use the build cycle/codestyle
rules defined within tools-parent.
#*# *Validation-aspect* := defines the globally availa
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315858#comment-315858
]
Lennart Jörelid edited comment on MSITE-669 at 12/18/12 12:52 AM:
--
I don't understand why a project which has a defined siteURL, located below the
rootURL (defined as the distributionManagement URL element of the topmost
project in the reactor) would need to consult its parent settings to define its
*staging directory*. If I understand you correctly, the rootURL for
{{site:stage}} is simply given by the distributionManagement/site/url element
in the pom where the {{mvn site:stage}} was launched.
Your statement, does however imply that the 3 rules for {{site:stage}} work
defined above do not fully describe the assumptions used by the
maven-site-plugin and its {{site:stage}} goal, but that we seem to have two
additional requirements:
# The {{site:stage}} goal assumes that all projects within the reactor use the
same parent.
# The parent project for all subprojects within a multimodule site:stage run
must be the reactor root (i.e. the project from where {{mvn site:stage}} was
run).
These assumptions feel rather constraining, to be honest.
My [obviously incorrect] conceptual model is/was that the parent project would
only be consulted to:
# Inherit/merge pom settings. (If no parent is defined, simply use what is
defined within the project itself.)
# Inherit/merge site.xml settings (If no parent is defined, simply use what is
defined within the subproject itself.)
# Read the distributionManagement URL setting within the parent pom in order to
create the link for
I would suggest that we describe these current requirements/assumptions within
the documentation for {{site:stage}}, and implement a change to make
{{site:stage}} yield a navigation structure matching the reactor's. In the case
of the nazgul_tools reactor, its build order structure is illustrated in an
attached image.
was (Author: l...@jguru.se):
I don't understand why a project which has a defined siteURL, located below
the rootURL (defined as the distributionManagement URL element of the topmost
project in the reactor) would need to consult its parent settings to define its
*staging directory*. That implies the 3 rules for {{site:stage}} work defined
above do not fully describe the assumptions used by the maven-site-plugin and
its {{site:stage}} goal, but that we seem to have two additional requirements:
# The {{site:stage}} goal assumes that all projects within the reactor use the
same parent.
# The parent project of a site:stage run must be the reactor root.
These assumptions feel rather constraining, to be honest.
My [obviously incorrect] conceptual model is/was that the parent project would
only be consulted to:
# Inherit/merge pom settings. (If no parent is defined, simply use what is
defined within the project itself.)
# Inherit/merge site.xml settings (If no parent is defined, simply use what is
defined within the subproject itself.)
# Read the distributionManagement URL setting within the parent pom in order to
create the link for
I would suggest that we describe these current requirements/assumptions within
the documentation for {{site:stage}}, and implement a change to make
{{site:stage}} yield a navigation structure matching the reactor's. In the case
of the nazgul_tools reactor, its build order structure is illustrated in an
attached image.
> site:stage creates incorrect structure when module paths contains sets of
> "../"
> ---
>
> Key: MSITE-669
> URL: https://jira.codehaus.org/browse/MSITE-669
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links, site:stage(-deploy)
>Affects Versions: 3.1, 3.2
>Reporter: Lennart Jörelid
>Assignee: Lukas Theussl
> Attachments: nazgul_tools_project_dependencies.png,
> nazgul_tools_project_dependencies.png, nazgul_tools_reactor_structure.png,
> sample.zip
>
>
> Given the module definitions given below, the site:stage goal produces sets
> of maps relative to the staging directory - i.e. outside of the target
> directory.
> {code:xml}
>
> ../../validation/validation-api
> ../../validation/validation-aspect
> ../parent
>
> {code}
> The staged site should be fully included within the staging directory. It
> would appear that relativization of links for site:stage should take special
> links into consideration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.at
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315861#comment-315861
]
Lennart Jörelid edited comment on MSITE-669 at 12/18/12 1:51 AM:
-
I attached images to clarify two things:
# The reactor build structure (module definitions). This is how I believe the
navigation within the site:stage should work (and - until recently - the way I
believed it *did* work).
#* Illustrated in image _nazgul_tools_reactor_structure_
#* White pom-type reactor projects only define modules and sites, thereby
glueing together the build reactor. Such projects do not produce anything worth
deploying - other than potential documentation which should be part of the
{{site:stage}}.
#* Yellow jar/bundle-type projects define a single deployable artifact, as well
as documentation in the form of a maven site. These project artifacts would be
deployed to a repo in a normal manner as well as part of a compound/staged site.
# The project dependencies including inclusions.
#* Illustrated by image _nazgul_tools_project_dependencies_. [Please remove the
earlier/incorrect of the two versions, as I cannot due to lacking privileges].
#* The reactor structure/projects briefly explained (to alleviate any
confusion):
#*# *Codestyle* := contains rules for checkstyle, enforcer, PMD etc. This is
essentially the implementation of the developer guidelines.
#*# *Tools-parent* := defines the build reactor, including dependency
management settings. The plugins use configuration/rules from the codestyle
project, implying that the tools-parent project include codestyle as a
dependency. Therefore, tools-parent is built after codestyle.
#*# *Validation-api* := defines the API of a globally available aspect. It
defines the tools-parent as parent project, to use the build cycle/codestyle
rules defined within tools-parent.
#*# *Validation-aspect* := defines the globally available aspect
implementation, depending on the validation-api and using the tools-parent as
parent project (to use the build cycle/codestyle rules defined within
tools-parent).
#*# *Parent* := configures AspectJ to use the aspect implementation from
validation-aspect. This makes the validation-aspect globally available to all
projects using the parent project as ... well ... parent.
Comments and thoughts on the above:
# It seems too invasive to require parent poms (i.e. tools-parent, parent) to
define modules just to acquire a staged site with working navigation. These
projects *should* be leaves, because they may be used as parents by poms
outside of the nazgul_tools reactor.
# It is practical to make all of the projects illustrated above be part of a
single reactor, since they are released as a unit - and should be documented as
a unit. I suggest that the {{site:stage}} should support this scenario.
# The structure I would expect from the {{site:stage}} command for the
nazgul_tools reactor, would match the reactor closely in terms of
links/navigation. The desired/expected structure of the
{{site:stage}}-generated site is identical to the one illustrated in the image
_nazgul_tools_reactor_structure_ above.
was (Author: l...@jguru.se):
I attached two images to clarify
# The reactor build structure (module definitions). This is how I believe the
navigation within the site:stage should work (and - until recently - the way I
believed it *did* work).
#* Illustrated in image _nazgul_tools_reactor_structure_
#* White pom-type reactor projects only define modules and sites, thereby
glueing together the build reactor. Such projects do not produce anything worth
deploying - other than potential documentation which should be part of the
{{site:stage}}.
#* Yellow jar/bundle-type projects define a single deployable artifact, as well
as documentation in the form of a maven site. These project artifacts would be
deployed to a repo in a normal manner as well as part of a compound/staged site.
# The project dependencies including inclusions.
#* Illustrated by image _nazgul_tools_project_dependencies_. [Please remove the
earlier/incorrect of the two versions, as I cannot due to lacking privileges].
#* The reactor structure/projects briefly explained (to alleviate any
confusion):
#*# *Codestyle* := contains rules for checkstyle, enforcer, PMD etc. This is
essentially the implementation of the developer guidelines.
#*# *Tools-parent* := defines the build reactor, including dependency
management settings. The plugins use configuration/rules from the codestyle
project, implying that the tools-parent project include codestyle as a
dependency. Therefore, tools-parent is built after codestyle.
#*# *Validation-api* := defines the API of a globally available aspect. It
defines the tools-parent as parent project, to use the build cycle/codestyle
rules defined within tools-parent.
#*# *Vali
