[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-tabpanelfocusedCommentId=319867#comment-319867
]
Lennart Jorelid commented on MSITE-669:
---
Back from vacation; got a few cycles this week to assign to this issue.
Will check sanity on the patch during the evening.
Meanwhile - could you validate that the documentation changes (on multisite
site generation) provided in this patch are sane/OK/makes sense?
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 Jorelid
Assignee: Lukas Theussl
Attachments: msite_669.patch, msite_669_v2.patch, msite_669_v3.patch,
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}
modules
module../../validation/validation-api/module
module../../validation/validation-aspect/module
module../parent/module
/modules
{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] (MCOMPILER-188) Add a flag to be able to disable incremental feature
[ https://jira.codehaus.org/browse/MCOMPILER-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MCOMPILER-188. -- Resolution: Fixed Assignee: Olivier Lamy fixed http://svn.apache.org/r1447251 Add a flag to be able to disable incremental feature Key: MCOMPILER-188 URL: https://jira.codehaus.org/browse/MCOMPILER-188 Project: Maven 2.x Compiler Plugin Issue Type: Improvement Affects Versions: 3.0 Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: 3.1 -- 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] (MCHECKSTYLE-186) FileTabCharacter check not working
[
https://jira.codehaus.org/browse/MCHECKSTYLE-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=319889#comment-319889
]
Dipti Desai commented on MCHECKSTYLE-186:
-
Thanks for your reply. I went through the linked issue and the revisions
mentioned there. I may be missing something out here but I didn't really find
anything specific that could validate my xml files. Could you please elaborate
a little on what could fix this issue?
FileTabCharacter check not working
--
Key: MCHECKSTYLE-186
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-186
Project: Maven 2.x Checkstyle Plugin
Issue Type: Bug
Reporter: Dipti Desai
Priority: Minor
The FileTabCharacter check doesnt seem to work. Below is my config:
{code:xml}
module name=Checker
..
..
!-- No TAB characters in the source code --
module name=FileTabCharacter
property name=eachLine value=true /
property name=fileExtensions value=java,xml /
/module
..
..
module name=TreeWalker
..
..
/module
/module
{code}
I have my xml files - pom.xml and checkstyle config xml containing tabs but
none of them are flagged as violations.
Some additional info - my plugin config looks like this:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-checkstyle-plugin/artifactId
version2.9.1/version
executions
execution
phaseverify/phase
goals
goalcheck/goal
/goals
/execution
/executions
configuration
configLocationcheckstyle/kepler-checkstyle-config.xml/configLocation
suppressionsLocation${project.parent.basedir}${file.separator}checkstyle/kepler-checkstyle-suppressions.xml/suppressionsLocation
/configuration
/plugin
{code}
--
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] (MRELEASE-777) release plugin shouldn't git clone if the SCM is git
[ https://jira.codehaus.org/browse/MRELEASE-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=319896#comment-319896 ] Anatoly Kupriyanov commented on MRELEASE-777: - I have a project which has several thousand files in it. So even hardlinks don't do the job significantly faster. And there is no way to tell the plugin to pull changes instead of cloning them. As I see in the source code, the release plugin v2.4 deletes the checkout directory first (CheckoutProjectFromScm.java:199), and it means that clone will be commenced always. The git clean should be used to create an clean copy to build. release plugin shouldn't git clone if the SCM is git Key: MRELEASE-777 URL: https://jira.codehaus.org/browse/MRELEASE-777 Project: Maven 2.x Release Plugin Issue Type: Improvement Environment: Linux x86_64, maven 2.2.1 Reporter: Joel Orlina Assignee: Mark Struberg See here for original issue: https://issues.sonatype.org/browse/MVNCENTRAL-202 -- 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] (MRELEASE-777) release plugin shouldn't git clone if the SCM is git
[ https://jira.codehaus.org/browse/MRELEASE-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=319897#comment-319897 ] Fred Cooke commented on MRELEASE-777: - My solution to this using variables wouldn't help you, however is likely correct from a historical point of view for most and would be a fraction faster than the hard-link clone. The trouble with your repo is that the hard links apply to the git objects, not the checked out tree, so merely creating a second copy is not acceptable for you, no matter how it's done. I've never understood why it's deemed necessary to create a second copy anyway. The system already checks to ensure that the original copy is clean before proceeding, why not just use it? +1 for an option to not do anything at all and just build in place. release plugin shouldn't git clone if the SCM is git Key: MRELEASE-777 URL: https://jira.codehaus.org/browse/MRELEASE-777 Project: Maven 2.x Release Plugin Issue Type: Improvement Environment: Linux x86_64, maven 2.2.1 Reporter: Joel Orlina Assignee: Mark Struberg See here for original issue: https://issues.sonatype.org/browse/MVNCENTRAL-202 -- 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] (MRELEASE-777) release plugin shouldn't git clone if the SCM is git
[ https://jira.codehaus.org/browse/MRELEASE-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=319905#comment-319905 ] Anatoly Kupriyanov commented on MRELEASE-777: - The release plugin does a lot strange things which ruin the performance. At the moment it creates a clone of wc, it build the project twice, it pollutes the wc with temporary files. Maybe it has a sense for some SCMs, but obviously not for git. For git the workflow should be: 1. Check local modifications, fail if any. 2. git clean -xdf 3. Set next version number 4. Commit 5. Create tag 6. mvn deploy 7. Make a snapshot version number 8. Commit 9. Push to git repo Maybe this is issue to solve in the v3.0. Or maybe for another release plugin. release plugin shouldn't git clone if the SCM is git Key: MRELEASE-777 URL: https://jira.codehaus.org/browse/MRELEASE-777 Project: Maven 2.x Release Plugin Issue Type: Improvement Environment: Linux x86_64, maven 2.2.1 Reporter: Joel Orlina Assignee: Mark Struberg See here for original issue: https://issues.sonatype.org/browse/MVNCENTRAL-202 -- 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] (MCHECKSTYLE-186) FileTabCharacter check not working
[
https://jira.codehaus.org/browse/MCHECKSTYLE-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=319908#comment-319908
]
Dennis Lundberg commented on MCHECKSTYLE-186:
-
Hi,
With the default configuration maven-checkstyle-plugin will only check java
files. If you want it to check xml files you need to configure the plugin to do
so.
Please use the includes configuration parameter.
FileTabCharacter check not working
--
Key: MCHECKSTYLE-186
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-186
Project: Maven 2.x Checkstyle Plugin
Issue Type: Bug
Reporter: Dipti Desai
Priority: Minor
The FileTabCharacter check doesnt seem to work. Below is my config:
{code:xml}
module name=Checker
..
..
!-- No TAB characters in the source code --
module name=FileTabCharacter
property name=eachLine value=true /
property name=fileExtensions value=java,xml /
/module
..
..
module name=TreeWalker
..
..
/module
/module
{code}
I have my xml files - pom.xml and checkstyle config xml containing tabs but
none of them are flagged as violations.
Some additional info - my plugin config looks like this:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-checkstyle-plugin/artifactId
version2.9.1/version
executions
execution
phaseverify/phase
goals
goalcheck/goal
/goals
/execution
/executions
configuration
configLocationcheckstyle/kepler-checkstyle-config.xml/configLocation
suppressionsLocation${project.parent.basedir}${file.separator}checkstyle/kepler-checkstyle-suppressions.xml/suppressionsLocation
/configuration
/plugin
{code}
--
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] (MRELEASE-777) release plugin shouldn't git clone if the SCM is git
[ https://jira.codehaus.org/browse/MRELEASE-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=319911#comment-319911 ] Fred Cooke commented on MRELEASE-777: - Building twice seems to me to be necessary. The first pass is a will it build OK pass BEFORE committing the pom modifications. Without this you have to chance it, and roll back the commit if broken, which seems messy, even if done manually. I can see the chancing it thing being useful on a huge project, but I can't see any reason to have such a huge project in the first place, to be honest ;-) However it's certainly possible for it to be legit, whether yours is or not, and that should be enough to better support it. So my vote is for chancing it to be optional if at all possible. I agree with your flow with one exception, clean -dxf, this is extremely dangerous and simply has to be an optional thing, if used at all. mvn clean should be sufficient, if not, your project seems to me to be broken. If you execute clean -dxf in some non-git sub-directory and have either your home dir or your root dir under git control with lots of stuff ignored, you're going to potentially nuke your entire account. Use with extreme caution. This IS a maven build, afterall. release plugin shouldn't git clone if the SCM is git Key: MRELEASE-777 URL: https://jira.codehaus.org/browse/MRELEASE-777 Project: Maven 2.x Release Plugin Issue Type: Improvement Environment: Linux x86_64, maven 2.2.1 Reporter: Joel Orlina Assignee: Mark Struberg See here for original issue: https://issues.sonatype.org/browse/MVNCENTRAL-202 -- 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] (MRELEASE-777) release plugin shouldn't git clone if the SCM is git
[ https://jira.codehaus.org/browse/MRELEASE-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=319925#comment-319925 ] Anatoly Kupriyanov commented on MRELEASE-777: - It is absolutely unnecessary for git. Until the commit is pushed outside, it is very easy to rollback with git reset. In my case the build runs a lot of integration tests which take nearly 20 minutes. It is not so good to run it twice. I am talking about the [workingDirectory|http://maven.apache.org/maven-release/maven-release-plugin/perform-mojo.html#workingDirectory], at the moment the plugin just deletes the folder. It makes even safer to do git clean instead. release plugin shouldn't git clone if the SCM is git Key: MRELEASE-777 URL: https://jira.codehaus.org/browse/MRELEASE-777 Project: Maven 2.x Release Plugin Issue Type: Improvement Environment: Linux x86_64, maven 2.2.1 Reporter: Joel Orlina Assignee: Mark Struberg See here for original issue: https://issues.sonatype.org/browse/MVNCENTRAL-202 -- 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] (MRELEASE-777) release plugin shouldn't git clone if the SCM is git
[ https://jira.codehaus.org/browse/MRELEASE-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=319929#comment-319929 ] Fred Cooke commented on MRELEASE-777: - Your usecase is just one. I have ignored pngs/ and tmp/ which devs are allowed/encouraged to put their screenies, WIPs and other random files in. Running git clean -dfx destroys everything, which is a BIG surprise and VERY unwelcome as a default. It's a maven build, maven clean should be sfufficient. If it is not, there are project structure problems to resolve (build output outside of target/). release plugin shouldn't git clone if the SCM is git Key: MRELEASE-777 URL: https://jira.codehaus.org/browse/MRELEASE-777 Project: Maven 2.x Release Plugin Issue Type: Improvement Environment: Linux x86_64, maven 2.2.1 Reporter: Joel Orlina Assignee: Mark Struberg See here for original issue: https://issues.sonatype.org/browse/MVNCENTRAL-202 -- 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] (MRELEASE-777) release plugin shouldn't git clone if the SCM is git
[ https://jira.codehaus.org/browse/MRELEASE-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=319929#comment-319929 ] Fred Cooke edited comment on MRELEASE-777 at 2/18/13 2:56 PM: -- Your usecase is just one. I have ignored pngs/ and tmp/ which devs are allowed/encouraged to put their screenies, WIPs and other random files in. Running git clean -dfx destroys everything, which is a BIG surprise and VERY unwelcome as a default. It's a maven build, maven clean should be sufficient. If it is not, there are project structure problems to resolve (build output outside of target/). was (Author: fredcooke): Your usecase is just one. I have ignored pngs/ and tmp/ which devs are allowed/encouraged to put their screenies, WIPs and other random files in. Running git clean -dfx destroys everything, which is a BIG surprise and VERY unwelcome as a default. It's a maven build, maven clean should be sfufficient. If it is not, there are project structure problems to resolve (build output outside of target/). release plugin shouldn't git clone if the SCM is git Key: MRELEASE-777 URL: https://jira.codehaus.org/browse/MRELEASE-777 Project: Maven 2.x Release Plugin Issue Type: Improvement Environment: Linux x86_64, maven 2.2.1 Reporter: Joel Orlina Assignee: Mark Struberg See here for original issue: https://issues.sonatype.org/browse/MVNCENTRAL-202 -- 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] (MRELEASE-777) release plugin shouldn't git clone if the SCM is git
[ https://jira.codehaus.org/browse/MRELEASE-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=319936#comment-319936 ] Anatoly Kupriyanov commented on MRELEASE-777: - It is unclear because I am not sure. :) It would be fine if the plugin at least doesn't delete the target/checkout, but pulls changes from the local repo (localCheckout parameter). It will work fast enough, updating only changed files, not the whole repository. However, in most cases it is even unnecessary, e.g. CI server could build in the basedir. So, it could be additional feature disabled by default, convenient for CIs. BTW, why the release plugin doesn't run build target/checkout straight away? release plugin shouldn't git clone if the SCM is git Key: MRELEASE-777 URL: https://jira.codehaus.org/browse/MRELEASE-777 Project: Maven 2.x Release Plugin Issue Type: Improvement Environment: Linux x86_64, maven 2.2.1 Reporter: Joel Orlina Assignee: Mark Struberg See here for original issue: https://issues.sonatype.org/browse/MVNCENTRAL-202 -- 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] (MRELEASE-777) release plugin shouldn't git clone if the SCM is git
[ https://jira.codehaus.org/browse/MRELEASE-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=319936#comment-319936 ] Anatoly Kupriyanov edited comment on MRELEASE-777 at 2/18/13 3:22 PM: -- It is unclear because I am not sure. :) It would be fine if the plugin at least doesn't delete the target/checkout, but pulls changes from the local repo (localCheckout parameter) and cleans it with git clean. It will work fast enough, updating only changed files, not the whole repository. However, in most cases it is even unnecessary, e.g. CI server could build in the basedir. So, it could be additional feature disabled by default, convenient for CIs. BTW, why the release plugin doesn't run build target/checkout straight away? was (Author: kan.izh): It is unclear because I am not sure. :) It would be fine if the plugin at least doesn't delete the target/checkout, but pulls changes from the local repo (localCheckout parameter). It will work fast enough, updating only changed files, not the whole repository. However, in most cases it is even unnecessary, e.g. CI server could build in the basedir. So, it could be additional feature disabled by default, convenient for CIs. BTW, why the release plugin doesn't run build target/checkout straight away? release plugin shouldn't git clone if the SCM is git Key: MRELEASE-777 URL: https://jira.codehaus.org/browse/MRELEASE-777 Project: Maven 2.x Release Plugin Issue Type: Improvement Environment: Linux x86_64, maven 2.2.1 Reporter: Joel Orlina Assignee: Mark Struberg See here for original issue: https://issues.sonatype.org/browse/MVNCENTRAL-202 -- 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-tabpanelfocusedCommentId=319956#comment-319956
]
Lennart Jorelid commented on MSITE-669:
---
I agree, Herve; it seems that the patch could/should be applied to the
stage-deploy goal as well - with the added twitch that one must also define
which URL should be used to find the site ID, to enable the stage-deploy goal
correctly interact with predefined userID and password given in a server
element within the effective settings.xml.
In stage-deploy, we have at least two URLs to play with:
# The [currently existing] stageSiteURL can be used to override the deployment
upload URL.
# The [to be added] rootSiteURL can be used to define how we should relativize
the intra-module links within the staged site.
I believe that the most logical choice in finding settings.xml-defined
UID/Password for upload of data would be to use the data defined within
settings.xml for the stageSiteURL, rather than the rootSiteURL. You agree
here? This implies that the standard behaviour is used unless overridden.
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 Jorelid
Assignee: Lukas Theussl
Attachments: msite_669.patch, msite_669_v2.patch, msite_669_v3.patch,
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}
modules
module../../validation/validation-api/module
module../../validation/validation-aspect/module
module../parent/module
/modules
{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
