[jira] Updated: (MJAVADOC-304) failOnError is ignored if javadoc:javadoc is called via Site Plugin 3.0-beta
[
http://jira.codehaus.org/browse/MJAVADOC-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Annies updated MJAVADOC-304:
--
Attachment: MJAVADOC-304_Patch.patch
MJAVADOC-304_IT_Test.patch
Integration Test (IT Test) and Patch.
failOnError is ignored if javadoc:javadoc is called via Site Plugin 3.0-beta
Key: MJAVADOC-304
URL: http://jira.codehaus.org/browse/MJAVADOC-304
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.7
Reporter: Sebastian Annies
Attachments: MJAVADOC-304_IT_Test.patch, MJAVADOC-304_Patch.patch
{{failOnError}} works for the case that javadoc:jar is executed. This
invocation calls {{execute()}} and then {{generate(sink, locale)}}. The
generate is surrounded with a try/catch-block catching any exception thrown
by the javadoc generation. In case of {{failOnError==false}} the exception
does not interrupt the build. That perfectly ok!
{{failOnError}} does not work if it is called during site generation. During
site generation only {{generate(sink, locale}} is called which misses the
try/catch guard for failures during generation of javadoc.
Effectively you cannot ignore failures during site generation.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAVADOC-304) failOnError is ignored if javadoc:javadoc is called via Site Plugin 3.0-beta
failOnError is ignored if javadoc:javadoc is called via Site Plugin 3.0-beta
Key: MJAVADOC-304
URL: http://jira.codehaus.org/browse/MJAVADOC-304
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.7
Reporter: Sebastian Annies
{{failOnError}} works for the case that javadoc:jar is executed. This
invocation calls {{execute()}} and then {{generate(sink, locale)}}. The
generate is surrounded with a try/catch-block catching any exception thrown by
the javadoc generation. In case of {{failOnError==false}} the exception does
not interrupt the build. That perfectly ok!
{{failOnError}} does not work if it is called during site generation. During
site generation only {{generate(sink, locale}} is called which misses the
try/catch guard for failures during generation of javadoc.
Effectively you cannot ignore failures during site generation.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-584) Checkout branch with Git uses unfamiliar command sequence which leads to errors during checkout
[
http://jira.codehaus.org/browse/SCM-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Annies updated SCM-584:
-
Attachment: SCM-584-test-prj.zip
A little project showing the error. I would have written a regular test but I
didn't understand the test framework. To see the error unzip and execute
{noformat}
mvn install
{noformat}
Checkout branch with Git uses unfamiliar command sequence which leads to
errors during checkout
---
Key: SCM-584
URL: http://jira.codehaus.org/browse/SCM-584
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-git
Affects Versions: 1.4
Reporter: Daniel Strassenburg
Priority: Critical
Attachments: SCM-584-test-prj.zip
I want to checkout a specific branch from my git repo using the
maven-scm-plugin. The plugin first clones the repo and gets the default
branch as selected in gitorious. After that the plugin executes git pull ...
mybranch which works fine as long as there are no merge conflicts between
current branch and branch to checkout. In the case of any conflict an error
occurs.
The git checkout -b command should be used instead.
{noformat}
[INFO] Working directory: a_dir
[INFO] Executing: /bin/sh -c cd /home/maven-proj/target/deploy-workspace
git fetch git://gitorious/.../my-proj.git
[INFO] Working directory: a_dir
[INFO] Executing: /bin/sh -c cd /home/maven-proj/target/deploy-workspace
git checkout HEAD
[INFO] Working directory: a_dir
[INFO] Executing: /bin/sh -c cd /home/maven-proj/target/deploy-workspace
git ls-files
[INFO] Working directory: a_dir
[INFO]
[INFO] --- maven-scm-plugin:1.4:update (switch-branch)
[INFO] Executing: /bin/sh -c cd /home/maven-proj/target/deploy-workspace
git pull git://gitorious/../deploy.git mysql55
[WARNING] failed to update git, return code 1
[ERROR] Provider message:
[ERROR] The git-pull origin master command failed.
[ERROR] Command output:
[ERROR] From git://gitorious/.../deploy
* branchmysql55- FETCH_HEAD
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-584) Checkout branch with Git uses unfamiliar command sequence which leads to errors during checkout
[
http://jira.codehaus.org/browse/SCM-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Annies updated SCM-584:
-
Attachment: SCM-584.patch
Patches the problem by appending the --branch parameter to the git command in
case the version is a branch. This makes sure that a subsequent pull does what
intended!
Checkout branch with Git uses unfamiliar command sequence which leads to
errors during checkout
---
Key: SCM-584
URL: http://jira.codehaus.org/browse/SCM-584
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-git
Affects Versions: 1.4
Reporter: Daniel Strassenburg
Priority: Critical
Attachments: SCM-584-test-prj.zip, SCM-584.patch
I want to checkout a specific branch from my git repo using the
maven-scm-plugin. The plugin first clones the repo and gets the default
branch as selected in gitorious. After that the plugin executes git pull ...
mybranch which works fine as long as there are no merge conflicts between
current branch and branch to checkout. In the case of any conflict an error
occurs.
The git checkout -b command should be used instead.
{noformat}
[INFO] Working directory: a_dir
[INFO] Executing: /bin/sh -c cd /home/maven-proj/target/deploy-workspace
git fetch git://gitorious/.../my-proj.git
[INFO] Working directory: a_dir
[INFO] Executing: /bin/sh -c cd /home/maven-proj/target/deploy-workspace
git checkout HEAD
[INFO] Working directory: a_dir
[INFO] Executing: /bin/sh -c cd /home/maven-proj/target/deploy-workspace
git ls-files
[INFO] Working directory: a_dir
[INFO]
[INFO] --- maven-scm-plugin:1.4:update (switch-branch)
[INFO] Executing: /bin/sh -c cd /home/maven-proj/target/deploy-workspace
git pull git://gitorious/../deploy.git mysql55
[WARNING] failed to update git, return code 1
[ERROR] Provider message:
[ERROR] The git-pull origin master command failed.
[ERROR] Command output:
[ERROR] From git://gitorious/.../deploy
* branchmysql55- FETCH_HEAD
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4918) MavenProject#clone() doubles active profiles
MavenProject#clone() doubles active profiles Key: MNG-4918 URL: http://jira.codehaus.org/browse/MNG-4918 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.0, 3.0.1 Environment: all Reporter: Sebastian Annies Attachments: test.patch The error occured in our Project with more than 60 submodules and aggregating JavaDoc. Due to the forking of the LifeCycle many clones of the MavenProject object seem to be performed. Since MavenProject#clone doubles the entries in the list of active profiles we start with one active profile and after a few dozen clones the list of active profiles exceeds 10.000.000 elements. This will than kill the VM by OOME. mavenProject.getActiveProfiles().size() == 1 mavenProject.clone().getActiveProfiles().size() == 2 mavenProject.clone().clone().getActiveProfiles().size() == 4 and so on -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4918) MavenProject#clone() doubles active profiles
[ http://jira.codehaus.org/browse/MNG-4918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Annies updated MNG-4918: -- Attachment: fix.patch A fix for the clone problem MavenProject#clone() doubles active profiles Key: MNG-4918 URL: http://jira.codehaus.org/browse/MNG-4918 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.0, 3.0.1 Environment: all Reporter: Sebastian Annies Attachments: fix.patch, test.patch The error occured in our Project with more than 60 submodules and aggregating JavaDoc. Due to the forking of the LifeCycle many clones of the MavenProject object seem to be performed. Since MavenProject#clone doubles the entries in the list of active profiles we start with one active profile and after a few dozen clones the list of active profiles exceeds 10.000.000 elements. This will than kill the VM by OOME. mavenProject.getActiveProfiles().size() == 1 mavenProject.clone().getActiveProfiles().size() == 2 mavenProject.clone().clone().getActiveProfiles().size() == 4 and so on -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MJAVADOC-299) excludePackageNames has no effect if subpackages is specified
[ http://jira.codehaus.org/browse/MJAVADOC-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Annies updated MJAVADOC-299: -- Attachment: MJAVADOC-299.zip MJAVADOC-299_IT_Test.patch An integrationtest to reproduce the described behavior as patch and as standalone zip with invoker testcase excludePackageNames has no effect if subpackages is specified - Key: MJAVADOC-299 URL: http://jira.codehaus.org/browse/MJAVADOC-299 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.7 Reporter: Paul Mealor Priority: Minor Attachments: MJAVADOC-299.zip, MJAVADOC-299_IT_Test.patch I am using a configuration something like the following: build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId version2.7/version executions execution configuration subpackagesfoo.bar.api/subpackages excludePackageNamesfoo.bar.api.impl:*impl:*.impl/excludePackageNames debugtrue/debug /configuration goals goaljar/goal /goals /execution /executions /plugin /plugins /build When I do this, every package under subpackages is included in my Javadoc, including foo.bar.api.impl. The @options file includes -subpackages foo.bar.api, but does not include -exclude. No @packages file is created. If I do not include subpackages/, the excludePackageNames/ works as desired: an @packages file is produced that excludes every package named like *.impl. Unfortunately, in my case, this means that packages like foo.bar.qux is included in the Javadoc, and I do not want that included. It would seem sensible if subpackages/ was used to generate the @packages file, the same as if no packages are specified. Then excludePackageNames/ could be applied to the list of packages in that file. My best workaround so far is to do the following, which tricks Javadoc and the plugin into building only foo.bar.api and foo.bar.api.event build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId version2.7/version executions execution configuration subpackagesnone/subpackages additionalparamfoo.bar.api foo.bar.api.event/additionalparam debugtrue/debug /configuration goals goaljar/goal /goals /execution /executions /plugin /plugins /build -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-489) Make Maven 3.x trunk compile against Maven 3.0-beta-1
Make Maven 3.x trunk compile against Maven 3.0-beta-1 - Key: MSITE-489 URL: http://jira.codehaus.org/browse/MSITE-489 Project: Maven 2.x Site Plugin Issue Type: Task Affects Versions: 3.0-beta-1 Reporter: Sebastian Annies Attachments: maven-3,0-beta-1.patch it uses alpha-7 at the moment. Please update to beta-1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-526) release:prepare 2.0 goal tags at the wrong level, tagging project/ instead of project/trunk
[
http://jira.codehaus.org/browse/MRELEASE-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=219055#action_219055
]
Sebastian Annies commented on MRELEASE-526:
---
Same for git. It's a blocker since. 2.0 is useless for git users as far as I
can see.
release:prepare 2.0 goal tags at the wrong level, tagging project/ instead of
project/trunk
---
Key: MRELEASE-526
URL: http://jira.codehaus.org/browse/MRELEASE-526
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.0
Environment: Maven 2.2.1
Reporter: Damien Coraboeuf
Priority: Critical
Fix For: 2.1
Attachments: export.zip
We have switched to the release plug-in 2.0 and are using the prepare goal as
we did before using version 2.0-beta-9. Unfortunately, the tag which is now
created is copied from the project level, and from the trunk. With version
2.0-beta-9, the tag was correctly copied from the trunk.
With 2.0-beta-9:
{noformat}
/project
|-- trunk/
|-- pom.xml
|-- src/
|-- tags/
|-- 4.0.1/ (-- copied from trunk
|-- pom.xml
|-- src/
{noformat}
With 2.0:
{noformat}
/project
|-- trunk/
|-- pom.xml
|-- src/
|-- tags/
|-- 4.0.1/ (-- copied from trunk
|-- trunk/
|-- pom.xml
|-- src/
|-- tags/
|-- branches/
{noformat}
Our _pom.xml_ SCM information is declared as follow:
{noformat}
scm
developerConnectionscm:svn:svn://host/path/project/trunk/developerConnection
/scm
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRELEASE-526) release:prepare 2.0 goal tags at the wrong level, tagging project/ instead of project/trunk
[
http://jira.codehaus.org/browse/MRELEASE-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=219055#action_219055
]
Sebastian Annies edited comment on MRELEASE-526 at 4/27/10 2:27 AM:
Same for git. It's a blocker since. 2.0 is useless for git users as far as I
can see.
Is this related to MRELEASE-546? Is it fixed by change 933531?
was (Author: sannies):
Same for git. It's a blocker since. 2.0 is useless for git users as far as
I can see.
release:prepare 2.0 goal tags at the wrong level, tagging project/ instead of
project/trunk
---
Key: MRELEASE-526
URL: http://jira.codehaus.org/browse/MRELEASE-526
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.0
Environment: Maven 2.2.1
Reporter: Damien Coraboeuf
Priority: Critical
Fix For: 2.1
Attachments: export.zip
We have switched to the release plug-in 2.0 and are using the prepare goal as
we did before using version 2.0-beta-9. Unfortunately, the tag which is now
created is copied from the project level, and from the trunk. With version
2.0-beta-9, the tag was correctly copied from the trunk.
With 2.0-beta-9:
{noformat}
/project
|-- trunk/
|-- pom.xml
|-- src/
|-- tags/
|-- 4.0.1/ (-- copied from trunk
|-- pom.xml
|-- src/
{noformat}
With 2.0:
{noformat}
/project
|-- trunk/
|-- pom.xml
|-- src/
|-- tags/
|-- 4.0.1/ (-- copied from trunk
|-- trunk/
|-- pom.xml
|-- src/
|-- tags/
|-- branches/
{noformat}
Our _pom.xml_ SCM information is declared as follow:
{noformat}
scm
developerConnectionscm:svn:svn://host/path/project/trunk/developerConnection
/scm
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DOXIA-382) Sink cannot be reused after parsing with ConfluenceParser
Sink cannot be reused after parsing with ConfluenceParser -- Key: DOXIA-382 URL: http://jira.codehaus.org/browse/DOXIA-382 Project: Maven Doxia Issue Type: Bug Components: Module - Confluence Affects Versions: 1.1.2 Reporter: Sebastian Annies Attachments: Patch_and_TestCase_for_DOXIA-382.patch The ConfluenceParser closes the Sink in #parse(Reader, Sink). That makes it impossible to reuse the sink as target for a second parse. So you won't be able to parse more than one Confluence document. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DOXIA-381) Using the render-books goal with confluence sources leads to incomplete output
[
http://jira.codehaus.org/browse/DOXIA-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Annies closed DOXIA-381.
--
Resolution: Duplicate
Using the render-books goal with confluence sources leads to incomplete output
--
Key: DOXIA-381
URL: http://jira.codehaus.org/browse/DOXIA-381
Project: Maven Doxia
Issue Type: Bug
Components: Book, Maven plugin, Module - Confluence
Affects Versions: 1.1.2
Environment: linux
java 1.6
Reporter: Sebastian Annies
Attachments: docbook-test.tar.bz2, TestCase_for_DOXIA-381.patch
my simple book example contains just one *.confluence file and one chapter.
When rendering doc-book or xhtml the generation of the xml just seems to stop
at the end of the confluence source without closing all the elements opened
before:
{code:xml}
book
bookinfo
titleUI Toolkit Documentation/title
/bookinfo
chapter
titleIntroduction and Overview/title
section
titleTypographic conventions/title
/section
paraWhile these seem quite some steps to achieve such a rather simple
task (edit a string property of some
article), most of this happens behind the scenes. You, as a UI
developer, only have to bind the text field to the
right model Bean and property, and everything else is taken care of.
/para -- The document just ends here!!!
{code}
attached as docbook-test.tar.bz2 is a demo project
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DOXIA-381) Using the render-books goal with confluence sources leads to incomplete output
Using the render-books goal with confluence sources leads to incomplete output
--
Key: DOXIA-381
URL: http://jira.codehaus.org/browse/DOXIA-381
Project: Maven Doxia
Issue Type: Bug
Components: Book, Maven plugin, Module - Confluence
Affects Versions: 1.1.2
Environment: linux
java 1.6
Reporter: Sebastian Annies
Attachments: docbook-test.tar.bz2
my simple book example contains just one *.confluence file and one chapter.
When rendering doc-book or xhtml the generation of the xml just seems to stop
at the end of the confluence source without closing all the elements opened
before:
{code:xml}
book
bookinfo
titleUI Toolkit Documentation/title
/bookinfo
chapter
titleIntroduction and Overview/title
section
titleTypographic conventions/title
/section
paraWhile these seem quite some steps to achieve such a rather simple
task (edit a string property of some
article), most of this happens behind the scenes. You, as a UI developer,
only have to bind the text field to the
right model Bean and property, and everything else is taken care of.
/para -- The document just ends here!!!
{code}
attached as docbook-test.tar.bz2 is a demo project
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DOXIA-381) Using the render-books goal with confluence sources leads to incomplete output
[
http://jira.codehaus.org/browse/DOXIA-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Annies updated DOXIA-381:
---
Attachment: TestCase_for_DOXIA-381.patch
Added a TestCase
Using the render-books goal with confluence sources leads to incomplete output
--
Key: DOXIA-381
URL: http://jira.codehaus.org/browse/DOXIA-381
Project: Maven Doxia
Issue Type: Bug
Components: Book, Maven plugin, Module - Confluence
Affects Versions: 1.1.2
Environment: linux
java 1.6
Reporter: Sebastian Annies
Attachments: docbook-test.tar.bz2, TestCase_for_DOXIA-381.patch
my simple book example contains just one *.confluence file and one chapter.
When rendering doc-book or xhtml the generation of the xml just seems to stop
at the end of the confluence source without closing all the elements opened
before:
{code:xml}
book
bookinfo
titleUI Toolkit Documentation/title
/bookinfo
chapter
titleIntroduction and Overview/title
section
titleTypographic conventions/title
/section
paraWhile these seem quite some steps to achieve such a rather simple
task (edit a string property of some
article), most of this happens behind the scenes. You, as a UI
developer, only have to bind the text field to the
right model Bean and property, and everything else is taken care of.
/para -- The document just ends here!!!
{code}
attached as docbook-test.tar.bz2 is a demo project
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-230) release:prepare cannot update the version of a module in a multi-module build if you have both normal artifact and attached artifact in dependencies
[ http://jira.codehaus.org/browse/MRELEASE-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=136765#action_136765 ] Sebastian Annies commented on MRELEASE-230: --- Is there any workaround? release:prepare cannot update the version of a module in a multi-module build if you have both normal artifact and attached artifact in dependencies Key: MRELEASE-230 URL: http://jira.codehaus.org/browse/MRELEASE-230 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-5 Reporter: Chris Wewerka Attachments: release-test.zip Following situation: you have a multimodule build with 2 modules A,B, and B has two dependencies to A, one for the normal jar artifact and one for an attached artifact (e.g. the test-jar of A). The release will fail with: ... [INFO] Transforming 'O2 Release test Base Module'... [INFO] Checking out file: E:\prj\o2\branches\main_latest\sd_pa\tools\release-test\pom.xml [INFO] Transforming 'release-test-module-one'... [INFO] Checking out file: E:\prj\o2\branches\main_latest\sd_pa\tools\release-test\release-test-module-one\pom.xml [INFO] Transforming 'release-test-module-two'... [INFO] Updating release-test-module-one to 5.0.2 [INFO] Updating release-test-module-one to 5.0.2 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] The version could not be updated: 5.0.2 [INFO] [INFO] For more information, run Maven with the -e switch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-370) generated client spec contains backslashes leading die problems on unix os
generated client spec contains backslashes leading die problems on unix os
--
Key: SCM-370
URL: http://jira.codehaus.org/browse/SCM-370
Project: Maven SCM
Issue Type: Improvement
Components: maven-scm-provider-perforce
Affects Versions: 1.0
Environment: UNIX
Reporter: Sebastian Annies
When a client is created it is named:
E.g.
{{sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6}}
that is ok, but now comes the sync command and uses following commandline
{{/bin/bash c p4 -d
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
-cbackground-sojus-MavenSCM\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
sync}}
The Bash now removes the backslashes in the client name! The result is that the
client is not existent and perforce returns with an error.
This is related to [PLXUTILS-44] and [CONTINUUM-1402]
I propose to use the underscore character instead of the backslash.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-370) generated client spec contains backslashes leading die problems on unix os
[
http://jira.codehaus.org/browse/SCM-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Annies updated SCM-370:
-
Attachment: SCM-351__SCM-370.patch
Modified generateDefaultClientspecName in PerforceScmProvider to generate
client spec without spaces, ~ and backslashes. This will fix [SCM-370] and
[SCM-351]
generated client spec contains backslashes leading die problems on unix os
--
Key: SCM-370
URL: http://jira.codehaus.org/browse/SCM-370
Project: Maven SCM
Issue Type: Improvement
Components: maven-scm-provider-perforce
Affects Versions: 1.0
Environment: UNIX
Reporter: Sebastian Annies
Attachments: SCM-351__SCM-370.patch
When a client is created it is named:
E.g.
{{sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6}}
that is ok, but now comes the sync command and uses following commandline
{{/bin/bash c p4 -d
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
-cbackground-sojus-MavenSCM\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
sync}}
The Bash now removes the backslashes in the client name! The result is that
the client is not existent and perforce returns with an error.
This is related to [PLXUTILS-44] and [CONTINUUM-1402]
I propose to use the underscore character instead of the backslash.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-351) generated client spec name fails if there is a space or tilde in directory name
[
http://jira.codehaus.org/browse/SCM-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127450
]
Sebastian Annies commented on SCM-351:
--
[SCM-370] is a very similar issue. I attached a patch there that will also fix
this one.
generated client spec name fails if there is a space or tilde in directory
name
---
Key: SCM-351
URL: http://jira.codehaus.org/browse/SCM-351
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-perforce
Affects Versions: 1.0
Reporter: zak jacobson
The default generated client spec name is calculated in
generateDefaultClientspecName() as:
username + minus; + hostname + minus;MavenSCMminus; + path;
if path includes a space or tilde, the client spec is not created and the
plugin fails to sync.
Can:
{noformat}path = workDir.getCanonicalPath().replace( '/', '\\' ){noformat}
be replaced with:
{noformat}path = workDir.getCanonicalPath().replace( '/', '\\'
).replaceAll([ ~], -){noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (SCM-370) generated client spec contains backslashes leading die problems on unix os
[
http://jira.codehaus.org/browse/SCM-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127449
]
sannies edited comment on SCM-370 at 3/17/08 6:35 AM:
---
Patch:
Modified generateDefaultClientspecName in PerforceScmProvider to generate
client spec without spaces, ~ and backslashes. This will fix [SCM-370] and
[SCM-351]
workdir is now translated to specname this way: path =
workDir.getCanonicalPath().replaceAll([/ ~], -);
was (Author: sannies):
Modified generateDefaultClientspecName in PerforceScmProvider to generate
client spec without spaces, ~ and backslashes. This will fix [SCM-370] and
[SCM-351]
generated client spec contains backslashes leading die problems on unix os
--
Key: SCM-370
URL: http://jira.codehaus.org/browse/SCM-370
Project: Maven SCM
Issue Type: Improvement
Components: maven-scm-provider-perforce
Affects Versions: 1.0
Environment: UNIX
Reporter: Sebastian Annies
Attachments: SCM-351__SCM-370.patch
When a client is created it is named:
E.g.
{{sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6}}
that is ok, but now comes the sync command and uses following commandline
{{/bin/bash c p4 -d
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
-cbackground-sojus-MavenSCM\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
sync}}
The Bash now removes the backslashes in the client name! The result is that
the client is not existent and perforce returns with an error.
This is related to [PLXUTILS-44] and [CONTINUUM-1402]
I propose to use the underscore character instead of the backslash.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAVADOC-178) Transitive Dependencies to Taglet Artifacts are not resolved nor added to the classpath
Transitive Dependencies to Taglet Artifacts are not resolved nor added to the
classpath
---
Key: MJAVADOC-178
URL: http://jira.codehaus.org/browse/MJAVADOC-178
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.3
Environment: any
Reporter: Sebastian Annies
Priority: Minor
Attachments: build-utils-1.0.9-SNAPSHOT.jar
My taglet artifact has a dependency to commons-lang. But when executing the
javadoc target the javadoc process complains with a ClassNotFoundException (in
my case {{StringEscapeUtils}} but that doesn't matter).
Hmm - I had a look into the source and as far as I can see it the transitive
dependencies are not resolved (only resolve is called and not
resolveTransitively).
The workaround is to specify the transitive dependencies by hand taglet
definitions without {{tagletClass}} elements:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
configuration
taglets
taglet
tagletClasscom.coremedia.drm.javadoc.api.ExampleTaglet/tagletClass
tagletArtifact
groupIdcom.coremedia.drm.roapserver/groupId
artifactIdbuild-utils/artifactId
version1.0.9-SNAPSHOT/version
/tagletArtifact
/taglet
taglet
tagletArtifact
groupIdcommons-lang/groupId
artifactIdcommons-lang/artifactId
version2.3/version
/tagletArtifact
/taglet
/taglets
/configuration
/plugin
{code}
To reproduce remove the second {{taglet}} element and include an [EMAIL
PROTECTED] tag in one of your classes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1402) Syncing with Perforce on Linux/Unix/Bash fails
[
http://jira.codehaus.org/browse/CONTINUUM-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115890
]
Sebastian Annies commented on CONTINUUM-1402:
-
No Workaround for me: I got 45 modules.
Syncing with Perforce on Linux/Unix/Bash fails
--
Key: CONTINUUM-1402
URL: http://jira.codehaus.org/browse/CONTINUUM-1402
Project: Continuum
Issue Type: Bug
Components: Integration - Maven 2, SCM
Affects Versions: 1.1-beta-2
Environment: Bash
Reporter: Sebastian Annies
Priority: Critical
When a client is created it is named:
E.g.{{monospaced}}
sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6{{monospaced}}
that is ok, but now comes the sync command and uses following commandline
{{monospaced}}
/bin/bash -c p4 -d
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
-cbackground-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
sync
{{monospaced}}
The Bash now removes the backslashes in the client name! The result is that
the client is not existent and perforce returns with an error.
I think continuum does everything allright but we need the ticket here to be
reminded to switch to a new plexus-utils or maven-scm if it is fixed there.
The Problem starts in 'PerforceCheckOutCommand':
{{monospaced}}
public static Commandline createCommandLine(
PerforceScmProviderRepository repo, File workingDirectory,
ScmVersion version, String
specname )
{
Commandline command = PerforceScmProvider.createP4Command( repo,
workingDirectory );
{color:red}
command.createArgument().setValue( -c + specname );
{color}
command.createArgument().setValue( sync );
// Use a simple heuristic to determine if we should use the Force flag
// on sync. Forcing sync is a HUGE performance hit but is required in
// rare instances where source is somehow deleted. If the target
// directory is completely empty, assume a force is required. If
// not empty, we assume a previous checkout was already done and a
normal
// sync will suffice.
// SCM-110
String[] files = workingDirectory.list();
if ( files == null || files.length == 0 )
{
// We need to force so checkout to an empty directory will work.
command.createArgument().setValue( -f );
}
// Not sure what to do here. I'm unclear whether we should be
// sync'ing each file individually to the label or just sync the
// entire contents of the workingDir. I'm going to assume the
// latter until the exact semantics are clearer.
if ( version != null StringUtils.isNotEmpty( version.getName() ) )
{
command.createArgument().setValue( @ + version.getName() );
}
return command;
{{monospaced}}
The {{monospaced}}specname {{monospaced}} contains the backslashes and is
these are neither escaped nor quoted! Hmm ... Is that a job that the
CommandLine should handle? I think so!
The next thing I will do is to file an issue at plexus-utils and link the
issues.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1402) Syncing with Perforce on Linux/Unix/Bash fails
[
http://jira.codehaus.org/browse/CONTINUUM-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109968
]
Sebastian Annies commented on CONTINUUM-1402:
-
this would require a fix in the Maven Perforce SCM Provider ...
Can you file an issue there and link it here?
Syncing with Perforce on Linux/Unix/Bash fails
--
Key: CONTINUUM-1402
URL: http://jira.codehaus.org/browse/CONTINUUM-1402
Project: Continuum
Issue Type: Bug
Components: Integration - Maven 2, SCM
Affects Versions: 1.1-beta-2
Environment: Bash
Reporter: Sebastian Annies
Priority: Critical
When a client is created it is named:
E.g.{{monospaced}}
sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6{{monospaced}}
that is ok, but now comes the sync command and uses following commandline
{{monospaced}}
/bin/bash -c p4 -d
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
-cbackground-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
sync
{{monospaced}}
The Bash now removes the backslashes in the client name! The result is that
the client is not existent and perforce returns with an error.
I think continuum does everything allright but we need the ticket here to be
reminded to switch to a new plexus-utils or maven-scm if it is fixed there.
The Problem starts in 'PerforceCheckOutCommand':
{{monospaced}}
public static Commandline createCommandLine(
PerforceScmProviderRepository repo, File workingDirectory,
ScmVersion version, String
specname )
{
Commandline command = PerforceScmProvider.createP4Command( repo,
workingDirectory );
{color:red}
command.createArgument().setValue( -c + specname );
{color}
command.createArgument().setValue( sync );
// Use a simple heuristic to determine if we should use the Force flag
// on sync. Forcing sync is a HUGE performance hit but is required in
// rare instances where source is somehow deleted. If the target
// directory is completely empty, assume a force is required. If
// not empty, we assume a previous checkout was already done and a
normal
// sync will suffice.
// SCM-110
String[] files = workingDirectory.list();
if ( files == null || files.length == 0 )
{
// We need to force so checkout to an empty directory will work.
command.createArgument().setValue( -f );
}
// Not sure what to do here. I'm unclear whether we should be
// sync'ing each file individually to the label or just sync the
// entire contents of the workingDir. I'm going to assume the
// latter until the exact semantics are clearer.
if ( version != null StringUtils.isNotEmpty( version.getName() ) )
{
command.createArgument().setValue( @ + version.getName() );
}
return command;
{{monospaced}}
The {{monospaced}}specname {{monospaced}} contains the backslashes and is
these are neither escaped nor quoted! Hmm ... Is that a job that the
CommandLine should handle? I think so!
The next thing I will do is to file an issue at plexus-utils and link the
issues.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (CONTINUUM-1402) Syncing with Perforce on Linux/Unix/Bash fails
[
http://jira.codehaus.org/browse/CONTINUUM-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106601
]
Sebastian Annies edited comment on CONTINUUM-1402 at 9/5/07 4:40 PM:
-
Can someone concerned please have a look into PLXUTILS-44 and comment my
comment? I just don't know how to fix that correctly! Any hints?
Concerning single quotes:
If the maven-scm provider adds the single quotes - what about windows then?
was:
Can someone concerned please have a look into PLXUTILS-44 and comment my
comment? I just don't know how to fix that correctly! Any hints?
Syncing with Perforce on Linux/Unix/Bash fails
--
Key: CONTINUUM-1402
URL: http://jira.codehaus.org/browse/CONTINUUM-1402
Project: Continuum
Issue Type: Bug
Components: Integration - Maven 2, SCM
Affects Versions: 1.1-beta-2
Environment: Bash
Reporter: Sebastian Annies
Priority: Critical
When a client is created it is named:
E.g.{{monospaced}}
sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6{{monospaced}}
that is ok, but now comes the sync command and uses following commandline
{{monospaced}}
/bin/bash -c p4 -d
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
-cbackground-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
sync
{{monospaced}}
The Bash now removes the backslashes in the client name! The result is that
the client is not existent and perforce returns with an error.
I think continuum does everything allright but we need the ticket here to be
reminded to switch to a new plexus-utils or maven-scm if it is fixed there.
The Problem starts in 'PerforceCheckOutCommand':
{{monospaced}}
public static Commandline createCommandLine(
PerforceScmProviderRepository repo, File workingDirectory,
ScmVersion version, String
specname )
{
Commandline command = PerforceScmProvider.createP4Command( repo,
workingDirectory );
{color:red}
command.createArgument().setValue( -c + specname );
{color}
command.createArgument().setValue( sync );
// Use a simple heuristic to determine if we should use the Force flag
// on sync. Forcing sync is a HUGE performance hit but is required in
// rare instances where source is somehow deleted. If the target
// directory is completely empty, assume a force is required. If
// not empty, we assume a previous checkout was already done and a
normal
// sync will suffice.
// SCM-110
String[] files = workingDirectory.list();
if ( files == null || files.length == 0 )
{
// We need to force so checkout to an empty directory will work.
command.createArgument().setValue( -f );
}
// Not sure what to do here. I'm unclear whether we should be
// sync'ing each file individually to the label or just sync the
// entire contents of the workingDir. I'm going to assume the
// latter until the exact semantics are clearer.
if ( version != null StringUtils.isNotEmpty( version.getName() ) )
{
command.createArgument().setValue( @ + version.getName() );
}
return command;
{{monospaced}}
The {{monospaced}}specname {{monospaced}} contains the backslashes and is
these are neither escaped nor quoted! Hmm ... Is that a job that the
CommandLine should handle? I think so!
The next thing I will do is to file an issue at plexus-utils and link the
issues.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1402) Syncing with Perforce on Linux/Unix/Bash fails
[
http://jira.codehaus.org/browse/CONTINUUM-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106601
]
Sebastian Annies commented on CONTINUUM-1402:
-
Can someone concerned please have a look into PLXUTILS-44 and comment my
comment? I just don't know how to fix that correctly! Any hints?
Syncing with Perforce on Linux/Unix/Bash fails
--
Key: CONTINUUM-1402
URL: http://jira.codehaus.org/browse/CONTINUUM-1402
Project: Continuum
Issue Type: Bug
Components: Integration - Maven 2, SCM
Affects Versions: 1.1-beta-2
Environment: Bash
Reporter: Sebastian Annies
Priority: Critical
When a client is created it is named:
E.g.{{monospaced}}
sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6{{monospaced}}
that is ok, but now comes the sync command and uses following commandline
{{monospaced}}
/bin/bash -c p4 -d
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
-cbackground-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
sync
{{monospaced}}
The Bash now removes the backslashes in the client name! The result is that
the client is not existent and perforce returns with an error.
I think continuum does everything allright but we need the ticket here to be
reminded to switch to a new plexus-utils or maven-scm if it is fixed there.
The Problem starts in 'PerforceCheckOutCommand':
{{monospaced}}
public static Commandline createCommandLine(
PerforceScmProviderRepository repo, File workingDirectory,
ScmVersion version, String
specname )
{
Commandline command = PerforceScmProvider.createP4Command( repo,
workingDirectory );
{color:red}
command.createArgument().setValue( -c + specname );
{color}
command.createArgument().setValue( sync );
// Use a simple heuristic to determine if we should use the Force flag
// on sync. Forcing sync is a HUGE performance hit but is required in
// rare instances where source is somehow deleted. If the target
// directory is completely empty, assume a force is required. If
// not empty, we assume a previous checkout was already done and a
normal
// sync will suffice.
// SCM-110
String[] files = workingDirectory.list();
if ( files == null || files.length == 0 )
{
// We need to force so checkout to an empty directory will work.
command.createArgument().setValue( -f );
}
// Not sure what to do here. I'm unclear whether we should be
// sync'ing each file individually to the label or just sync the
// entire contents of the workingDir. I'm going to assume the
// latter until the exact semantics are clearer.
if ( version != null StringUtils.isNotEmpty( version.getName() ) )
{
command.createArgument().setValue( @ + version.getName() );
}
return command;
{{monospaced}}
The {{monospaced}}specname {{monospaced}} contains the backslashes and is
these are neither escaped nor quoted! Hmm ... Is that a job that the
CommandLine should handle? I think so!
The next thing I will do is to file an issue at plexus-utils and link the
issues.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1402) Syncing with Perforce on Linux/Unix/Bash fails
[
http://jira.codehaus.org/browse/CONTINUUM-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106309
]
Sebastian Annies commented on CONTINUUM-1402:
-
I will provide a plexus-utils fix in the next days (perhaps I can even get this
done today)
Syncing with Perforce on Linux/Unix/Bash fails
--
Key: CONTINUUM-1402
URL: http://jira.codehaus.org/browse/CONTINUUM-1402
Project: Continuum
Issue Type: Bug
Components: Integration - Maven 2, SCM
Affects Versions: 1.1-beta-2
Environment: Bash
Reporter: Sebastian Annies
Priority: Critical
When a client is created it is named:
E.g.{{monospaced}}
sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6{{monospaced}}
that is ok, but now comes the sync command and uses following commandline
{{monospaced}}
/bin/bash -c p4 -d
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
-cbackground-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
sync
{{monospaced}}
The Bash now removes the backslashes in the client name! The result is that
the client is not existent and perforce returns with an error.
I think continuum does everything allright but we need the ticket here to be
reminded to switch to a new plexus-utils or maven-scm if it is fixed there.
The Problem starts in 'PerforceCheckOutCommand':
{{monospaced}}
public static Commandline createCommandLine(
PerforceScmProviderRepository repo, File workingDirectory,
ScmVersion version, String
specname )
{
Commandline command = PerforceScmProvider.createP4Command( repo,
workingDirectory );
{color:red}
command.createArgument().setValue( -c + specname );
{color}
command.createArgument().setValue( sync );
// Use a simple heuristic to determine if we should use the Force flag
// on sync. Forcing sync is a HUGE performance hit but is required in
// rare instances where source is somehow deleted. If the target
// directory is completely empty, assume a force is required. If
// not empty, we assume a previous checkout was already done and a
normal
// sync will suffice.
// SCM-110
String[] files = workingDirectory.list();
if ( files == null || files.length == 0 )
{
// We need to force so checkout to an empty directory will work.
command.createArgument().setValue( -f );
}
// Not sure what to do here. I'm unclear whether we should be
// sync'ing each file individually to the label or just sync the
// entire contents of the workingDir. I'm going to assume the
// latter until the exact semantics are clearer.
if ( version != null StringUtils.isNotEmpty( version.getName() ) )
{
command.createArgument().setValue( @ + version.getName() );
}
return command;
{{monospaced}}
The {{monospaced}}specname {{monospaced}} contains the backslashes and is
these are neither escaped nor quoted! Hmm ... Is that a job that the
CommandLine should handle? I think so!
The next thing I will do is to file an issue at plexus-utils and link the
issues.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1351) Acnnot checkout sources - perforce.
[ http://jira.codehaus.org/browse/CONTINUUM-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106036 ] Sebastian Annies commented on CONTINUUM-1351: - This issue is not very specific. Could you please give us more info? What SCM? Error Log? etc? by now I can't say whether it is related to CONTINUUM-1402 Acnnot checkout sources - perforce. --- Key: CONTINUUM-1351 URL: http://jira.codehaus.org/browse/CONTINUUM-1351 Project: Continuum Issue Type: Bug Affects Versions: 1.1-beta-1 Environment: Linux Reporter: Duncan McNaught The pom files work in 1.1-alpha-2 but after creating a new 1.1-beta-1 release I get the following build error: Exception: Cannot checkout sources. Index: 0, Size: 0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1402) Syncing with Perforce on Linux/Unix/Bash fails
Syncing with Perforce on Linux/Unix/Bash fails
--
Key: CONTINUUM-1402
URL: http://jira.codehaus.org/browse/CONTINUUM-1402
Project: Continuum
Issue Type: Bug
Components: Integration - Maven 2, SCM
Affects Versions: 1.1-beta-2
Environment: Bash
Reporter: Sebastian Annies
Priority: Critical
When a client is created it is named:
E.g.{{monospaced}}
sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6{{monospaced}}
that is ok, but now comes the sync command and uses following commandline
{{monospaced}}
/bin/bash -c p4 -d
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
-cbackground-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
sync
{{monospaced}}
The Bash now removes the backslashes in the client name! The result is that the
client is not existent and perforce returns with an error.
I think continuum does everything allright but we need the ticket here to be
reminded to switch to a new plexus-utils or maven-scm if it is fixed there.
The Problem starts in 'PerforceCheckOutCommand':
{{monospaced}}
public static Commandline createCommandLine( PerforceScmProviderRepository
repo, File workingDirectory,
ScmVersion version, String
specname )
{
Commandline command = PerforceScmProvider.createP4Command( repo,
workingDirectory );
{color:red}
command.createArgument().setValue( -c + specname );
{color}
command.createArgument().setValue( sync );
// Use a simple heuristic to determine if we should use the Force flag
// on sync. Forcing sync is a HUGE performance hit but is required in
// rare instances where source is somehow deleted. If the target
// directory is completely empty, assume a force is required. If
// not empty, we assume a previous checkout was already done and a
normal
// sync will suffice.
// SCM-110
String[] files = workingDirectory.list();
if ( files == null || files.length == 0 )
{
// We need to force so checkout to an empty directory will work.
command.createArgument().setValue( -f );
}
// Not sure what to do here. I'm unclear whether we should be
// sync'ing each file individually to the label or just sync the
// entire contents of the workingDir. I'm going to assume the
// latter until the exact semantics are clearer.
if ( version != null StringUtils.isNotEmpty( version.getName() ) )
{
command.createArgument().setValue( @ + version.getName() );
}
return command;
{{monospaced}}
The {{monospaced}}specname {{monospaced}} contains the backslashes and is
these are neither escaped nor quoted! Hmm ... Is that a job that the
CommandLine should handle? I think so!
The next thing I will do is to file an issue at plexus-utils and link the
issues.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (CONTINUUM-1402) Syncing with Perforce on Linux/Unix/Bash fails
[
http://jira.codehaus.org/browse/CONTINUUM-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105305
]
Sebastian Annies edited comment on CONTINUUM-1402 at 8/21/07 7:41 AM:
--
MORE READABLE HERE:
When a client is created it is named:
E.g.
{{sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6}}
that is ok, but now comes the sync command and uses following commandline
{{/bin/bash c p4 -d
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
-cbackground-sojus-MavenSCM\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
sync}}
The Bash now removes the backslashes in the client name! The result is that the
client is not existent and perforce returns with an error.
I think continuum does everything allright but we need the ticket here to be
reminded to switch to a new plexus-utils or maven-scm if it is fixed there.
The Problem starts in 'PerforceCheckOutCommand':
{quote}public static Commandline createCommandLine(
PerforceScmProviderRepository repo, File workingDirectory,
ScmVersion version,
String specname )
{
Commandline command = PerforceScmProvider.createP4Command( repo,
workingDirectory );
{color:red}command.createArgument().setValue( -c + specname );{color}
command.createArgument().setValue( sync );
// Use a simple heuristic to determine if we should use the Force flag
// on sync. Forcing sync is a HUGE performance hit but is required in
// rare instances where source is somehow deleted. If the target
// directory is completely empty, assume a force is required. If
// not empty, we assume a previous checkout was already done and a normal
// sync will suffice.
// SCM-110
String[] files = workingDirectory.list();
if ( files == null || files.length == 0 )
{
// We need to force so checkout to an empty directory will work.
command.createArgument().setValue( -f ); }
// Not sure what to do here. I'm unclear whether we should be
// sync'ing each file individually to the label or just sync the
// entire contents of the workingDir. I'm going to assume the
// latter until the exact semantics are clearer.
if ( version != null StringUtils.isNotEmpty( version.getName() ) )
{ command.createArgument().setValue( @ + version.getName() ); }
}
{quote}
The {{specname}} contains the backslashes and is these are neither escaped nor
quoted! Hmm ... Is that a job that the CommandLine should handle? I think so!
The next thing I will do is to file an issue at plexus-utils and link the
issues.
was:
MORE READABLE HERE:
When a client is created it is named:
E.g.
{{sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6}}
that is ok, but now comes the sync command and uses following commandline
{{/bin/bash c p4 -d
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
-cbackground-sojus-MavenSCM\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
sync}}
The Bash now removes the backslashes in the client name! The result is that the
client is not existent and perforce returns with an error.
I think continuum does everything allright but we need the ticket here to be
reminded to switch to a new plexus-utils or maven-scm if it is fixed there.
The Problem starts in 'PerforceCheckOutCommand':
{{public static Commandline createCommandLine( PerforceScmProviderRepository
repo, File workingDirectory,
ScmVersion version,
String specname )
{
Commandline command = PerforceScmProvider.createP4Command( repo,
workingDirectory );
{color:red}command.createArgument().setValue( -c + specname );{color}
command.createArgument().setValue( sync );
// Use a simple heuristic to determine if we should use the Force flag
// on sync. Forcing sync is a HUGE performance hit but is required in
// rare instances where source is somehow deleted. If the target
// directory is completely empty, assume a force is required. If
// not empty, we assume a previous checkout was already done and a normal
// sync will suffice.
// SCM-110
String[] files = workingDirectory.list();
if ( files == null || files.length == 0 )
{
// We need to force so checkout to an empty directory will work.
command.createArgument().setValue( -f ); }
// Not sure what to do here. I'm unclear whether we should be
// sync'ing each file individually to the label or just sync the
// entire contents of the workingDir. I'm going to assume the
// latter until the exact semantics are clearer.
if ( version != null StringUtils.isNotEmpty( version.getName() ) )
{ command.createArgument().setValue( @ + version.getName() ); }
}
}}
The
[jira] Issue Comment Edited: (CONTINUUM-1402) Syncing with Perforce on Linux/Unix/Bash fails
[
http://jira.codehaus.org/browse/CONTINUUM-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105305
]
Sebastian Annies edited comment on CONTINUUM-1402 at 8/21/07 7:40 AM:
--
MORE READABLE HERE:
When a client is created it is named:
E.g.
{{sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6}}
that is ok, but now comes the sync command and uses following commandline
{{/bin/bash c p4 -d
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
-cbackground-sojus-MavenSCM\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
sync}}
The Bash now removes the backslashes in the client name! The result is that the
client is not existent and perforce returns with an error.
I think continuum does everything allright but we need the ticket here to be
reminded to switch to a new plexus-utils or maven-scm if it is fixed there.
The Problem starts in 'PerforceCheckOutCommand':
{{public static Commandline createCommandLine( PerforceScmProviderRepository
repo, File workingDirectory,
ScmVersion version,
String specname )
{
Commandline command = PerforceScmProvider.createP4Command( repo,
workingDirectory );
{color:red}command.createArgument().setValue( -c + specname );{color}
command.createArgument().setValue( sync );
// Use a simple heuristic to determine if we should use the Force flag
// on sync. Forcing sync is a HUGE performance hit but is required in
// rare instances where source is somehow deleted. If the target
// directory is completely empty, assume a force is required. If
// not empty, we assume a previous checkout was already done and a normal
// sync will suffice.
// SCM-110
String[] files = workingDirectory.list();
if ( files == null || files.length == 0 )
{
// We need to force so checkout to an empty directory will work.
command.createArgument().setValue( -f ); }
// Not sure what to do here. I'm unclear whether we should be
// sync'ing each file individually to the label or just sync the
// entire contents of the workingDir. I'm going to assume the
// latter until the exact semantics are clearer.
if ( version != null StringUtils.isNotEmpty( version.getName() ) )
{ command.createArgument().setValue( @ + version.getName() ); }
}
}}
The {{specname}} contains the backslashes and is these are neither escaped nor
quoted! Hmm ... Is that a job that the CommandLine should handle? I think so!
The next thing I will do is to file an issue at plexus-utils and link the
issues.
was:
MORE READABLE HERE:
When a client is created it is named:
E.g.
{{sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6}}
that is ok, but now comes the sync command and uses following commandline
{{/bin/bash c p4 -d
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
-cbackground-sojus-MavenSCM\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
sync}}
The Bash now removes the backslashes in the client name! The result is that the
client is not existent and perforce returns with an error.
I think continuum does everything allright but we need the ticket here to be
reminded to switch to a new plexus-utils or maven-scm if it is fixed there.
The Problem starts in 'PerforceCheckOutCommand':
{{public static Commandline createCommandLine( PerforceScmProviderRepository
repo, File workingDirectory,
ScmVersion version,
String specname )
{
Commandline command = PerforceScmProvider.createP4Command( repo,
workingDirectory );
{color.red}
command.createArgument().setValue( -c + specname );{color}
command.createArgument().setValue( sync );
// Use a simple heuristic to determine if we should use the Force flag
// on sync. Forcing sync is a HUGE performance hit but is required in
// rare instances where source is somehow deleted. If the target
// directory is completely empty, assume a force is required. If
// not empty, we assume a previous checkout was already done and a normal
// sync will suffice.
// SCM-110
String[] files = workingDirectory.list();
if ( files == null || files.length == 0 )
{
// We need to force so checkout to an empty directory will work.
command.createArgument().setValue( -f ); }
// Not sure what to do here. I'm unclear whether we should be
// sync'ing each file individually to the label or just sync the
// entire contents of the workingDir. I'm going to assume the
// latter until the exact semantics are clearer.
if ( version != null StringUtils.isNotEmpty( version.getName() ) )
{ command.createArgument().setValue( @ + version.getName() ); }
}
}}
The {{specname}}
[jira] Issue Comment Edited: (CONTINUUM-1402) Syncing with Perforce on Linux/Unix/Bash fails
[
http://jira.codehaus.org/browse/CONTINUUM-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105305
]
Sebastian Annies edited comment on CONTINUUM-1402 at 8/21/07 7:39 AM:
--
MORE READABLE HERE:
When a client is created it is named:
E.g.
{{sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6}}
that is ok, but now comes the sync command and uses following commandline
{{/bin/bash c p4 -d
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
-cbackground-sojus-MavenSCM\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
sync}}
The Bash now removes the backslashes in the client name! The result is that the
client is not existent and perforce returns with an error.
I think continuum does everything allright but we need the ticket here to be
reminded to switch to a new plexus-utils or maven-scm if it is fixed there.
The Problem starts in 'PerforceCheckOutCommand':
{{public static Commandline createCommandLine( PerforceScmProviderRepository
repo, File workingDirectory,
ScmVersion version,
String specname )
{
Commandline command = PerforceScmProvider.createP4Command( repo,
workingDirectory );
{color.red}
command.createArgument().setValue( -c + specname );{color}
command.createArgument().setValue( sync );
// Use a simple heuristic to determine if we should use the Force flag
// on sync. Forcing sync is a HUGE performance hit but is required in
// rare instances where source is somehow deleted. If the target
// directory is completely empty, assume a force is required. If
// not empty, we assume a previous checkout was already done and a normal
// sync will suffice.
// SCM-110
String[] files = workingDirectory.list();
if ( files == null || files.length == 0 )
{
// We need to force so checkout to an empty directory will work.
command.createArgument().setValue( -f ); }
// Not sure what to do here. I'm unclear whether we should be
// sync'ing each file individually to the label or just sync the
// entire contents of the workingDir. I'm going to assume the
// latter until the exact semantics are clearer.
if ( version != null StringUtils.isNotEmpty( version.getName() ) )
{ command.createArgument().setValue( @ + version.getName() ); }
}
}}
The {{specname}} contains the backslashes and is these are neither escaped nor
quoted! Hmm ... Is that a job that the CommandLine should handle? I think so!
The next thing I will do is to file an issue at plexus-utils and link the
issues.
was:
MORE READABLE HERE:
When a client is created it is named:
E.g.
{{sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6}}
that is ok, but now comes the sync command and uses following commandline
{{/bin/bash c p4 -d
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
-cbackground-sojus-MavenSCM\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
sync}}
The Bash now removes the backslashes in the client name! The result is that the
client is not existent and perforce returns with an error.
I think continuum does everything allright but we need the ticket here to be
reminded to switch to a new plexus-utils or maven-scm if it is fixed there.
The Problem starts in 'PerforceCheckOutCommand':
{{
public static Commandline createCommandLine( PerforceScmProviderRepository
repo, File workingDirectory,
ScmVersion version,
String specname )
{
Commandline command = PerforceScmProvider.createP4Command( repo,
workingDirectory );
{color.red}
command.createArgument().setValue( -c + specname );{color}
command.createArgument().setValue( sync );
// Use a simple heuristic to determine if we should use the Force flag
// on sync. Forcing sync is a HUGE performance hit but is required in
// rare instances where source is somehow deleted. If the target
// directory is completely empty, assume a force is required. If
// not empty, we assume a previous checkout was already done and a normal
// sync will suffice.
// SCM-110
String[] files = workingDirectory.list();
if ( files == null || files.length == 0 )
{
// We need to force so checkout to an empty directory will work.
command.createArgument().setValue( -f ); }
// Not sure what to do here. I'm unclear whether we should be
// sync'ing each file individually to the label or just sync the
// entire contents of the workingDir. I'm going to assume the
// latter until the exact semantics are clearer.
if ( version != null StringUtils.isNotEmpty( version.getName() ) )
{ command.createArgument().setValue( @ + version.getName() ); }
}
}}
The {{specname }}
[jira] Issue Comment Edited: (CONTINUUM-1402) Syncing with Perforce on Linux/Unix/Bash fails
[
http://jira.codehaus.org/browse/CONTINUUM-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105305
]
Sebastian Annies edited comment on CONTINUUM-1402 at 8/21/07 10:15 AM:
---
MORE READABLE HERE:
When a client is created it is named:
E.g.
{{sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6}}
that is ok, but now comes the sync command and uses following commandline
{{/bin/bash c p4 -d
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
-cbackground-sojus-MavenSCM\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
sync}}
The Bash now removes the backslashes in the client name! The result is that the
client is not existent and perforce returns with an error.
I think continuum does everything allright but we need the ticket here to be
reminded to switch to a new plexus-utils or maven-scm if it is fixed there.
The Problem starts in 'PerforceCheckOutCommand':
{quote}public static Commandline createCommandLine(
PerforceScmProviderRepository repo, File workingDirectory,
ScmVersion version,
String specname )
{
Commandline command = PerforceScmProvider.createP4Command( repo,
workingDirectory );
{color:red}command.createArgument().setValue( -c + specname );{color}
command.createArgument().setValue( sync );
// Use a simple heuristic to determine if we should use the Force flag
// on sync. Forcing sync is a HUGE performance hit but is required in
// rare instances where source is somehow deleted. If the target
// directory is completely empty, assume a force is required. If
// not empty, we assume a previous checkout was already done and a normal
// sync will suffice.
// SCM-110
String[] files = workingDirectory.list();
if ( files == null || files.length == 0 )
{
// We need to force so checkout to an empty directory will work.
command.createArgument().setValue( -f ); }
// Not sure what to do here. I'm unclear whether we should be
// sync'ing each file individually to the label or just sync the
// entire contents of the workingDir. I'm going to assume the
// latter until the exact semantics are clearer.
if ( version != null StringUtils.isNotEmpty( version.getName() ) )
\{ command.createArgument().setValue( @ + version.getName() ); \}
}
{quote}
The {{specname}} contains the backslashes and is these are neither escaped nor
quoted! Hmm ... Is that a job that the CommandLine should handle? I think so!
The next thing I will do is to file an issue at plexus-utils and link the
issues.
was:
MORE READABLE HERE:
When a client is created it is named:
E.g.
{{sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6}}
that is ok, but now comes the sync command and uses following commandline
{{/bin/bash c p4 -d
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
-cbackground-sojus-MavenSCM\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
sync}}
The Bash now removes the backslashes in the client name! The result is that the
client is not existent and perforce returns with an error.
I think continuum does everything allright but we need the ticket here to be
reminded to switch to a new plexus-utils or maven-scm if it is fixed there.
The Problem starts in 'PerforceCheckOutCommand':
{quote}public static Commandline createCommandLine(
PerforceScmProviderRepository repo, File workingDirectory,
ScmVersion version,
String specname )
{
Commandline command = PerforceScmProvider.createP4Command( repo,
workingDirectory );
{color:red}command.createArgument().setValue( -c + specname );{color}
command.createArgument().setValue( sync );
// Use a simple heuristic to determine if we should use the Force flag
// on sync. Forcing sync is a HUGE performance hit but is required in
// rare instances where source is somehow deleted. If the target
// directory is completely empty, assume a force is required. If
// not empty, we assume a previous checkout was already done and a normal
// sync will suffice.
// SCM-110
String[] files = workingDirectory.list();
if ( files == null || files.length == 0 )
{
// We need to force so checkout to an empty directory will work.
command.createArgument().setValue( -f ); }
// Not sure what to do here. I'm unclear whether we should be
// sync'ing each file individually to the label or just sync the
// entire contents of the workingDir. I'm going to assume the
// latter until the exact semantics are clearer.
if ( version != null StringUtils.isNotEmpty( version.getName() ) )
{ command.createArgument().setValue( @ + version.getName() ); }
}
{quote}
[jira] Issue Comment Edited: (CONTINUUM-1402) Syncing with Perforce on Linux/Unix/Bash fails
[
http://jira.codehaus.org/browse/CONTINUUM-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105305
]
Sebastian Annies edited comment on CONTINUUM-1402 at 8/21/07 10:16 AM:
---
MORE READABLE HERE:
When a client is created it is named:
E.g.
{{sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6}}
that is ok, but now comes the sync command and uses following commandline
{{/bin/bash c p4 -d
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
-cbackground-sojus-MavenSCM\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
sync}}
The Bash now removes the backslashes in the client name! The result is that the
client is not existent and perforce returns with an error.
I think continuum does everything allright but we need the ticket here to be
reminded to switch to a new plexus-utils or maven-scm if it is fixed there.
The Problem starts in 'PerforceCheckOutCommand':
{quote}public static Commandline createCommandLine(
PerforceScmProviderRepository repo, File workingDirectory,
ScmVersion version,
String specname )
{
Commandline command = PerforceScmProvider.createP4Command( repo,
workingDirectory );
{color:red}command.createArgument().setValue( -c + specname );{color}
command.createArgument().setValue( sync );
// Use a simple heuristic to determine if we should use the Force flag
// on sync. Forcing sync is a HUGE performance hit but is required in
// rare instances where source is somehow deleted. If the target
// directory is completely empty, assume a force is required. If
// not empty, we assume a previous checkout was already done and a normal
// sync will suffice.
// SCM-110
String[] files = workingDirectory.list();
if ( files == null || files.length == 0 )
\{
// We need to force so checkout to an empty directory will work.
command.createArgument().setValue( -f );
\}
// Not sure what to do here. I'm unclear whether we should be
// sync'ing each file individually to the label or just sync the
// entire contents of the workingDir. I'm going to assume the
// latter until the exact semantics are clearer.
if ( version != null StringUtils.isNotEmpty( version.getName() ) ) \{
command.createArgument().setValue( @ + version.getName() );
\}
}
{quote}
The {{specname}} contains the backslashes and is these are neither escaped nor
quoted! Hmm ... Is that a job that the CommandLine should handle? I think so!
The next thing I will do is to file an issue at plexus-utils and link the
issues.
was:
MORE READABLE HERE:
When a client is created it is named:
E.g.
{{sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6}}
that is ok, but now comes the sync command and uses following commandline
{{/bin/bash c p4 -d
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
-cbackground-sojus-MavenSCM\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
sync}}
The Bash now removes the backslashes in the client name! The result is that the
client is not existent and perforce returns with an error.
I think continuum does everything allright but we need the ticket here to be
reminded to switch to a new plexus-utils or maven-scm if it is fixed there.
The Problem starts in 'PerforceCheckOutCommand':
{quote}public static Commandline createCommandLine(
PerforceScmProviderRepository repo, File workingDirectory,
ScmVersion version,
String specname )
{
Commandline command = PerforceScmProvider.createP4Command( repo,
workingDirectory );
{color:red}command.createArgument().setValue( -c + specname );{color}
command.createArgument().setValue( sync );
// Use a simple heuristic to determine if we should use the Force flag
// on sync. Forcing sync is a HUGE performance hit but is required in
// rare instances where source is somehow deleted. If the target
// directory is completely empty, assume a force is required. If
// not empty, we assume a previous checkout was already done and a normal
// sync will suffice.
// SCM-110
String[] files = workingDirectory.list();
if ( files == null || files.length == 0 )
{
// We need to force so checkout to an empty directory will work.
command.createArgument().setValue( -f ); }
// Not sure what to do here. I'm unclear whether we should be
// sync'ing each file individually to the label or just sync the
// entire contents of the workingDir. I'm going to assume the
// latter until the exact semantics are clearer.
if ( version != null StringUtils.isNotEmpty( version.getName() ) )
\{ command.createArgument().setValue( @ + version.getName() );
[jira] Closed: (CONTINUUM-1274) Release Project fails due to pom.xml not writable with perforce as SCM
[ http://jira.codehaus.org/browse/CONTINUUM-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Annies closed CONTINUUM-1274. --- Resolution: Fixed Fix Version/s: (was: Future) 1.1-alpha-2 it works since alpha-2 - hmmm Release Project fails due to pom.xml not writable with perforce as SCM -- Key: CONTINUUM-1274 URL: http://jira.codehaus.org/browse/CONTINUUM-1274 Project: Continuum Issue Type: Bug Components: Integration - Maven 2, SCM Affects Versions: 1.1-alpha-1 Environment: ubunto 7.04 java 6 Reporter: Sebastian Annies Priority: Critical Fix For: 1.1-alpha-2 All release steps from update-working-copy to map-development-versions work fine. The next phase ' rewrite-poms-for-release' fails because of read-only pom.xml. this could be an issue with the scmUseEdit flag since perforce file are read-only by default. see log output: (I tried to fix alpha-2 by myself therfor log output is alpha2-SNAPSHOT, error reproduces with alpha-1, too) [INFO] Updating local copy against the scm... [INFO] Verifying that there are no local modifications... [INFO] Checking dependencies and plugins for snapshots ... [ERROR] org.apache.maven.shared.release.ReleaseExecutionException: Error writing POM: /home/drmtest/continuum-1.1-alpha-2-SNAPSHOT/continuum-webapp/src/main/webapp/WEB-INF/working-directory/1/pom.xml (Permission denied) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:659) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:604) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:190) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:115) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.execute(AbstractRewritePomsPhase.java:98) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) at org.apache.maven.shared.release.DefaultReleaseManager.prepareWithResult(DefaultReleaseManager.java:107) at org.apache.maven.continuum.release.executors.PrepareReleaseTaskExecutor.execute(PrepareReleaseTaskExecutor.java:43) at org.apache.maven.continuum.release.executors.AbstractReleaseTaskExecutor.executeTask(AbstractReleaseTaskExecutor.java:67) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:987) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:528) at java.lang.Thread.run(Thread.java:619) Caused by: java.io.FileNotFoundException: /home/drmtest/continuum-1.1-alpha-2-SNAPSHOT/continuum-webapp/src/main/webapp/WEB-INF/working-directory/1/pom.xml (Permission denied) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:179) at java.io.FileOutputStream.init(FileOutputStream.java:131) at java.io.FileWriter.init(FileWriter.java:73) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:640) ... 14 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1352) Introduce a mail size limit
Introduce a mail size limit --- Key: CONTINUUM-1352 URL: http://jira.codehaus.org/browse/CONTINUUM-1352 Project: Continuum Issue Type: New Feature Components: Integration - Maven 2, Notification Subsystem, Notifier - Mail Affects Versions: 1.1-beta-1 Environment: all Reporter: Sebastian Annies Priority: Minor our integration tests produce ~30MB log output. This output is send by mail and causes our mail quota to be exceeded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHANGELOG-66) changelog for perforce fails because of default clientspec
[
http://jira.codehaus.org/browse/MCHANGELOG-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102683
]
Sebastian Annies commented on MCHANGELOG-66:
I don't think that this is a issue with the changelog plugin. There are many
issues filed for the perforce scm provider that all deal with the same problem
(and that is the problem here, too):
The Perforce SCM Provider does not know under which client the files are
located.
This problem can only be fixed partly with the clientspec.name system property
since there is only one system property in a system but we have several client
as it is the case with continuum.
- The Perforce SCM Provider should deal with this issue exactly as perforce
users deal with it everyday: We use a .p4config with clientspec name in it.
changelog for perforce fails because of default clientspec
--
Key: MCHANGELOG-66
URL: http://jira.codehaus.org/browse/MCHANGELOG-66
Project: Maven 2.x Changelog Plugin
Issue Type: Bug
Affects Versions: 2.0
Reporter: Brian Jackson
Currently changelog fails for Perforce when the default clientspec is used
and the plugin provides no way to supply the clientspec name. Currently you
can do the following for the scm plugin so that the scm:changelog will work:
plugin
artifactIdmaven-scm-plugin/artifactId
configuration
systemProperties
property
namemaven.scm.perforce.clientspec.name/name
value${perforce.clientspec.name.from.settings.xml}/value
/property
/systemProperties
/configuration
/plugin
I propose the same for the changelog report plugin.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MCHANGELOG-66) changelog for perforce fails because of default clientspec
[
http://jira.codehaus.org/browse/MCHANGELOG-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102683
]
Sebastian Annies edited comment on MCHANGELOG-66 at 7/19/07 7:10 AM:
-
I don't think that this is a issue with the changelog plugin. There are many
issues filed for the perforce scm provider that all deal with the same problem
(and that is the problem here, too):
The Perforce SCM Provider does not know under which client the files are
located.
This problem can only be fixed partly with the clientspec.name system property
since there is only one system property in a system but we have several clients
as it is the case with continuum.
- The Perforce SCM Provider should deal with this issue exactly as perforce
users deal with it everyday: We use a .p4config with clientspec name in it.
was:
I don't think that this is a issue with the changelog plugin. There are many
issues filed for the perforce scm provider that all deal with the same problem
(and that is the problem here, too):
The Perforce SCM Provider does not know under which client the files are
located.
This problem can only be fixed partly with the clientspec.name system property
since there is only one system property in a system but we have several client
as it is the case with continuum.
- The Perforce SCM Provider should deal with this issue exactly as perforce
users deal with it everyday: We use a .p4config with clientspec name in it.
changelog for perforce fails because of default clientspec
--
Key: MCHANGELOG-66
URL: http://jira.codehaus.org/browse/MCHANGELOG-66
Project: Maven 2.x Changelog Plugin
Issue Type: Bug
Affects Versions: 2.0
Reporter: Brian Jackson
Currently changelog fails for Perforce when the default clientspec is used
and the plugin provides no way to supply the clientspec name. Currently you
can do the following for the scm plugin so that the scm:changelog will work:
plugin
artifactIdmaven-scm-plugin/artifactId
configuration
systemProperties
property
namemaven.scm.perforce.clientspec.name/name
value${perforce.clientspec.name.from.settings.xml}/value
/property
/systemProperties
/configuration
/plugin
I propose the same for the changelog report plugin.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (CONTINUUM-1274) Release Project fails due to pom.xml not writable with perforce as SCM
[ http://jira.codehaus.org/browse/CONTINUUM-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96294 ] Sebastian Annies edited comment on CONTINUUM-1274 at 5/19/07 5:08 AM: -- - was: Logging should be improved. I have to debug everything, cause logging doesn't log enough (or at least debug log level is disabled and I got no idea how to enable) Release Project fails due to pom.xml not writable with perforce as SCM -- Key: CONTINUUM-1274 URL: http://jira.codehaus.org/browse/CONTINUUM-1274 Project: Continuum Issue Type: Bug Components: Integration - Maven 2, SCM Affects Versions: 1.1-alpha-1 Environment: ubunto 7.04 java 6 Reporter: Sebastian Annies Priority: Critical All release steps from update-working-copy to map-development-versions work fine. The next phase ' rewrite-poms-for-release' fails because of read-only pom.xml. this could be an issue with the scmUseEdit flag since perforce file are read-only by default. see log output: (I tried to fix alpha-2 by myself therfor log output is alpha2-SNAPSHOT, error reproduces with alpha-1, too) [INFO] Updating local copy against the scm... [INFO] Verifying that there are no local modifications... [INFO] Checking dependencies and plugins for snapshots ... [ERROR] org.apache.maven.shared.release.ReleaseExecutionException: Error writing POM: /home/drmtest/continuum-1.1-alpha-2-SNAPSHOT/continuum-webapp/src/main/webapp/WEB-INF/working-directory/1/pom.xml (Permission denied) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:659) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:604) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:190) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:115) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.execute(AbstractRewritePomsPhase.java:98) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) at org.apache.maven.shared.release.DefaultReleaseManager.prepareWithResult(DefaultReleaseManager.java:107) at org.apache.maven.continuum.release.executors.PrepareReleaseTaskExecutor.execute(PrepareReleaseTaskExecutor.java:43) at org.apache.maven.continuum.release.executors.AbstractReleaseTaskExecutor.executeTask(AbstractReleaseTaskExecutor.java:67) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:987) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:528) at java.lang.Thread.run(Thread.java:619) Caused by: java.io.FileNotFoundException: /home/drmtest/continuum-1.1-alpha-2-SNAPSHOT/continuum-webapp/src/main/webapp/WEB-INF/working-directory/1/pom.xml (Permission denied) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:179) at java.io.FileOutputStream.init(FileOutputStream.java:131) at java.io.FileWriter.init(FileWriter.java:73) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:640) ... 14 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (CONTINUUM-1274) Release Project fails due to pom.xml not writable with perforce as SCM
[ http://jira.codehaus.org/browse/CONTINUUM-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96294 ] Sebastian Annies edited comment on CONTINUUM-1274 at 5/19/07 5:43 AM: -- is this related to [SCM-281]? was: - Release Project fails due to pom.xml not writable with perforce as SCM -- Key: CONTINUUM-1274 URL: http://jira.codehaus.org/browse/CONTINUUM-1274 Project: Continuum Issue Type: Bug Components: Integration - Maven 2, SCM Affects Versions: 1.1-alpha-1 Environment: ubunto 7.04 java 6 Reporter: Sebastian Annies Priority: Critical All release steps from update-working-copy to map-development-versions work fine. The next phase ' rewrite-poms-for-release' fails because of read-only pom.xml. this could be an issue with the scmUseEdit flag since perforce file are read-only by default. see log output: (I tried to fix alpha-2 by myself therfor log output is alpha2-SNAPSHOT, error reproduces with alpha-1, too) [INFO] Updating local copy against the scm... [INFO] Verifying that there are no local modifications... [INFO] Checking dependencies and plugins for snapshots ... [ERROR] org.apache.maven.shared.release.ReleaseExecutionException: Error writing POM: /home/drmtest/continuum-1.1-alpha-2-SNAPSHOT/continuum-webapp/src/main/webapp/WEB-INF/working-directory/1/pom.xml (Permission denied) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:659) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:604) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:190) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:115) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.execute(AbstractRewritePomsPhase.java:98) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) at org.apache.maven.shared.release.DefaultReleaseManager.prepareWithResult(DefaultReleaseManager.java:107) at org.apache.maven.continuum.release.executors.PrepareReleaseTaskExecutor.execute(PrepareReleaseTaskExecutor.java:43) at org.apache.maven.continuum.release.executors.AbstractReleaseTaskExecutor.executeTask(AbstractReleaseTaskExecutor.java:67) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:987) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:528) at java.lang.Thread.run(Thread.java:619) Caused by: java.io.FileNotFoundException: /home/drmtest/continuum-1.1-alpha-2-SNAPSHOT/continuum-webapp/src/main/webapp/WEB-INF/working-directory/1/pom.xml (Permission denied) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:179) at java.io.FileOutputStream.init(FileOutputStream.java:131) at java.io.FileWriter.init(FileWriter.java:73) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:640) ... 14 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (CONTINUUM-1274) Release Project fails due to pom.xml not writable with perforce as SCM
[ http://jira.codehaus.org/browse/CONTINUUM-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96293 ] Sebastian Annies edited comment on CONTINUUM-1274 at 5/19/07 9:25 AM: -- the perforce adapter shows an error: cannot find depot = using //applications/buildng-drm-roapserver/helgoland/drm-roapserver 19.5.: 2007-05-19 16:09:27,953 [pool-3-thread-1] ERROR ReleasePhase:rewrite-poms-for-release - Command Output: Path 'C:\svn\working-directory\1\pom.xml' is not under client's root 'c:\p4\packager'. Okay, I know what's wrong, the release-manager does not know what client it has to use and tries it with no client. That means default client. And the pom.xml it is trying to edit is not in the default client. How can I get the client's name in the edit command!? The checkOut command uses a client by appending -cclient. Why doesn't the edit command? WHAT A STUPID SITUATION. DAMN: If I add the client to the edit command the local mvn release:prepare will not run anymore since in this case a default client is used. If I don't add the client I cannot build with continuum since there we cannot use default client (since there is more than one client - Multimodule) HHH! was: the perforce adapter shows an error: cannot find depot = using //applications/buildng-drm-roapserver/helgoland/drm-roapserver i got no idea. Release Project fails due to pom.xml not writable with perforce as SCM -- Key: CONTINUUM-1274 URL: http://jira.codehaus.org/browse/CONTINUUM-1274 Project: Continuum Issue Type: Bug Components: Integration - Maven 2, SCM Affects Versions: 1.1-alpha-1 Environment: ubunto 7.04 java 6 Reporter: Sebastian Annies Priority: Critical All release steps from update-working-copy to map-development-versions work fine. The next phase ' rewrite-poms-for-release' fails because of read-only pom.xml. this could be an issue with the scmUseEdit flag since perforce file are read-only by default. see log output: (I tried to fix alpha-2 by myself therfor log output is alpha2-SNAPSHOT, error reproduces with alpha-1, too) [INFO] Updating local copy against the scm... [INFO] Verifying that there are no local modifications... [INFO] Checking dependencies and plugins for snapshots ... [ERROR] org.apache.maven.shared.release.ReleaseExecutionException: Error writing POM: /home/drmtest/continuum-1.1-alpha-2-SNAPSHOT/continuum-webapp/src/main/webapp/WEB-INF/working-directory/1/pom.xml (Permission denied) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:659) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:604) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:190) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:115) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.execute(AbstractRewritePomsPhase.java:98) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) at org.apache.maven.shared.release.DefaultReleaseManager.prepareWithResult(DefaultReleaseManager.java:107) at org.apache.maven.continuum.release.executors.PrepareReleaseTaskExecutor.execute(PrepareReleaseTaskExecutor.java:43) at org.apache.maven.continuum.release.executors.AbstractReleaseTaskExecutor.executeTask(AbstractReleaseTaskExecutor.java:67) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:987) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:528) at java.lang.Thread.run(Thread.java:619) Caused by: java.io.FileNotFoundException: /home/drmtest/continuum-1.1-alpha-2-SNAPSHOT/continuum-webapp/src/main/webapp/WEB-INF/working-directory/1/pom.xml (Permission denied) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:179) at java.io.FileOutputStream.init(FileOutputStream.java:131) at java.io.FileWriter.init(FileWriter.java:73) at
[jira] Commented: (SCM-281) Perforce problem: incorrect client spec is used
[ http://jira.codehaus.org/browse/SCM-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96364 ] Sebastian Annies commented on SCM-281: -- The client spec seems to be a major problem with the perforce integration. I propose to use the P4CONFIG mechanism (or a mechanism similar to it). 1. the perforce commands should watch out for a file named .p4clientspec (just as an example) in the directory they are working in 2. if the file exists, read it and use its content as client name. 3. if a client is created by checkout command this file has to be written What do you think? Perforce problem: incorrect client spec is used --- Key: SCM-281 URL: http://jira.codehaus.org/browse/SCM-281 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-perforce Affects Versions: 1.0-beta-4 Reporter: Anton Katernoga Assignee: Mike Perham Fix For: future Attachments: patch.p4.txt I have 2 projects set up which use the same perforce scm url. One is run each 5 mins, the other is a nightly tests build. I've noticed that the latter never gets run-the message is that the dir is up-to date. It appeared that after the first project is run, its client spec is set to system variable in PerforceCheckOutCommand (maven-scm perforce provider) class and afterwards the value of the var is used instead of a correct client spec. I didn't remove the property set, as it is a fix to SCM-165, but rather the place where prop is used. Now works fine. Patch is attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1274) Release Project fails due to pom.xml not writable with perforce as SCM
[
http://jira.codehaus.org/browse/CONTINUUM-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96369
]
Sebastian Annies commented on CONTINUUM-1274:
-
I fixed this issue for myself (works for me and I don't what it may break). In
the PerforceCheckOutCommand I added code for generation of a .p4config file. if
P4CONFIG is set to .p4config Perforce can and will take care of finding the
client by itself.
if (consumer.isSuccess()) {
File p4config = new File(workingDirectory, .p4config);
if (!p4config.exists()) {
try {
FileWriter fw = new FileWriter(p4config);
fw.write(P4CLIENT= + specname);
fw.close();
} catch (IOException e) {
throw new ScmException(could not create .p4config, e);
}
}
return new CheckOutScmResult(cl.toString(), consumer.getCheckedout());
(But I found another flaw: Even though persistCheckout is turned on the main
project's client will be changed up on release:perform. The root will be
changed to workingDirectory-somestring , so during release:perform the client
is not persistent and subsequent continous builds will change it back)
Release Project fails due to pom.xml not writable with perforce as SCM
--
Key: CONTINUUM-1274
URL: http://jira.codehaus.org/browse/CONTINUUM-1274
Project: Continuum
Issue Type: Bug
Components: Integration - Maven 2, SCM
Affects Versions: 1.1-alpha-1
Environment: ubunto 7.04 java 6
Reporter: Sebastian Annies
Priority: Critical
All release steps from update-working-copy to map-development-versions work
fine. The next phase ' rewrite-poms-for-release' fails because of read-only
pom.xml.
this could be an issue with the scmUseEdit flag since perforce file are
read-only by default.
see log output:
(I tried to fix alpha-2 by myself therfor log output is alpha2-SNAPSHOT,
error reproduces with alpha-1, too)
[INFO] Updating local copy against the scm...
[INFO] Verifying that there are no local modifications...
[INFO] Checking dependencies and plugins for snapshots ...
[ERROR] org.apache.maven.shared.release.ReleaseExecutionException: Error
writing POM:
/home/drmtest/continuum-1.1-alpha-2-SNAPSHOT/continuum-webapp/src/main/webapp/WEB-INF/working-directory/1/pom.xml
(Permission denied)
at
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:659)
at
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:604)
at
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:190)
at
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:115)
at
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.execute(AbstractRewritePomsPhase.java:98)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepareWithResult(DefaultReleaseManager.java:107)
at
org.apache.maven.continuum.release.executors.PrepareReleaseTaskExecutor.execute(PrepareReleaseTaskExecutor.java:43)
at
org.apache.maven.continuum.release.executors.AbstractReleaseTaskExecutor.executeTask(AbstractReleaseTaskExecutor.java:67)
at
org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116)
at
edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
at
edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:987)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:528)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.io.FileNotFoundException:
/home/drmtest/continuum-1.1-alpha-2-SNAPSHOT/continuum-webapp/src/main/webapp/WEB-INF/working-directory/1/pom.xml
(Permission denied)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.init(FileOutputStream.java:179)
at java.io.FileOutputStream.init(FileOutputStream.java:131)
at java.io.FileWriter.init(FileWriter.java:73)
at
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:640)
... 14 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
[jira] Commented: (CONTINUUM-1274) Release Project fails due to pom.xml not writable with perforce as SCM
[ http://jira.codehaus.org/browse/CONTINUUM-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96281 ] Sebastian Annies commented on CONTINUUM-1274: - I added some log to the AbstractRewritePomsPhase.java source: 2007-05-18 14:52:46,186 [pool-3-thread-1] ERROR ReleasePhase:rewrite-poms-for-release - We are about to write the pom 2007-05-18 14:52:46,186 [pool-3-thread-1] ERROR ReleasePhase:rewrite-poms-for-release - releaseDescriptor.isScmUseEditMode(): false 2007-05-18 14:52:46,186 [pool-3-thread-1] ERROR ReleasePhase:rewrite-poms-for-release - provider.requiresEditMode(): true 2007-05-18 14:52:46,186 [pool-3-thread-1] ERROR ReleasePhase:rewrite-poms-for-release - Okay let's make C:\svn\continuum\working-directory\1\pom.xml writable. -- Here we executeEditScmResult result = provider.edit(repository, new ScmFileSet(new File(releaseDescriptor.getWorkingDirectory()), pomFile)); 2007-05-18 14:52:46,514 [pool-3-thread-1] ERROR ReleasePhase:rewrite-poms-for-release - Edit Files: [] 2007-05-18 14:52:46,514 [pool-3-thread-1] ERROR ReleasePhase:rewrite-poms-for-release - Success: true 2007-05-18 14:52:46,514 [pool-3-thread-1] ERROR ReleasePhase:rewrite-poms-for-release - Command Line: p4 -d C:\svn\continuum\working-directory\1 -u ** -P * edit pom.xml 2007-05-18 14:52:46,514 [pool-3-thread-1] ERROR ReleasePhase:rewrite-poms-for-release - Command Output: null 2007-05-18 14:52:46,514 [pool-3-thread-1] ERROR ReleasePhase:rewrite-poms-for-release - Provider message: null Hmm - no command output. What happens in the perforceProvider. I'll check it out. Wait for more info Release Project fails due to pom.xml not writable with perforce as SCM -- Key: CONTINUUM-1274 URL: http://jira.codehaus.org/browse/CONTINUUM-1274 Project: Continuum Issue Type: Bug Components: Integration - Maven 2, SCM Affects Versions: 1.1-alpha-1 Environment: ubunto 7.04 java 6 Reporter: Sebastian Annies Priority: Critical All release steps from update-working-copy to map-development-versions work fine. The next phase ' rewrite-poms-for-release' fails because of read-only pom.xml. this could be an issue with the scmUseEdit flag since perforce file are read-only by default. see log output: (I tried to fix alpha-2 by myself therfor log output is alpha2-SNAPSHOT, error reproduces with alpha-1, too) [INFO] Updating local copy against the scm... [INFO] Verifying that there are no local modifications... [INFO] Checking dependencies and plugins for snapshots ... [ERROR] org.apache.maven.shared.release.ReleaseExecutionException: Error writing POM: /home/drmtest/continuum-1.1-alpha-2-SNAPSHOT/continuum-webapp/src/main/webapp/WEB-INF/working-directory/1/pom.xml (Permission denied) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:659) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:604) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:190) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:115) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.execute(AbstractRewritePomsPhase.java:98) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) at org.apache.maven.shared.release.DefaultReleaseManager.prepareWithResult(DefaultReleaseManager.java:107) at org.apache.maven.continuum.release.executors.PrepareReleaseTaskExecutor.execute(PrepareReleaseTaskExecutor.java:43) at org.apache.maven.continuum.release.executors.AbstractReleaseTaskExecutor.executeTask(AbstractReleaseTaskExecutor.java:67) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:987) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:528) at java.lang.Thread.run(Thread.java:619) Caused by: java.io.FileNotFoundException: /home/drmtest/continuum-1.1-alpha-2-SNAPSHOT/continuum-webapp/src/main/webapp/WEB-INF/working-directory/1/pom.xml (Permission denied) at java.io.FileOutputStream.open(Native Method) at
[jira] Commented: (CONTINUUM-1274) Release Project fails due to pom.xml not writable with perforce as SCM
[ http://jira.codehaus.org/browse/CONTINUUM-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96294 ] Sebastian Annies commented on CONTINUUM-1274: - Logging should be improved. I have to debug everything, cause logging doesn't log enough Release Project fails due to pom.xml not writable with perforce as SCM -- Key: CONTINUUM-1274 URL: http://jira.codehaus.org/browse/CONTINUUM-1274 Project: Continuum Issue Type: Bug Components: Integration - Maven 2, SCM Affects Versions: 1.1-alpha-1 Environment: ubunto 7.04 java 6 Reporter: Sebastian Annies Priority: Critical All release steps from update-working-copy to map-development-versions work fine. The next phase ' rewrite-poms-for-release' fails because of read-only pom.xml. this could be an issue with the scmUseEdit flag since perforce file are read-only by default. see log output: (I tried to fix alpha-2 by myself therfor log output is alpha2-SNAPSHOT, error reproduces with alpha-1, too) [INFO] Updating local copy against the scm... [INFO] Verifying that there are no local modifications... [INFO] Checking dependencies and plugins for snapshots ... [ERROR] org.apache.maven.shared.release.ReleaseExecutionException: Error writing POM: /home/drmtest/continuum-1.1-alpha-2-SNAPSHOT/continuum-webapp/src/main/webapp/WEB-INF/working-directory/1/pom.xml (Permission denied) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:659) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:604) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:190) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:115) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.execute(AbstractRewritePomsPhase.java:98) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) at org.apache.maven.shared.release.DefaultReleaseManager.prepareWithResult(DefaultReleaseManager.java:107) at org.apache.maven.continuum.release.executors.PrepareReleaseTaskExecutor.execute(PrepareReleaseTaskExecutor.java:43) at org.apache.maven.continuum.release.executors.AbstractReleaseTaskExecutor.executeTask(AbstractReleaseTaskExecutor.java:67) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:987) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:528) at java.lang.Thread.run(Thread.java:619) Caused by: java.io.FileNotFoundException: /home/drmtest/continuum-1.1-alpha-2-SNAPSHOT/continuum-webapp/src/main/webapp/WEB-INF/working-directory/1/pom.xml (Permission denied) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:179) at java.io.FileOutputStream.init(FileOutputStream.java:131) at java.io.FileWriter.init(FileWriter.java:73) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:640) ... 14 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (CONTINUUM-1274) Release Project fails due to pom.xml not writable with perforce as SCM
[ http://jira.codehaus.org/browse/CONTINUUM-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96294 ] Sebastian Annies edited comment on CONTINUUM-1274 at 5/18/07 7:01 PM: -- Logging should be improved. I have to debug everything, cause logging doesn't log enough (or at least debug log level is disabled and I got no idea how to enable) was: Logging should be improved. I have to debug everything, cause logging doesn't log enough Release Project fails due to pom.xml not writable with perforce as SCM -- Key: CONTINUUM-1274 URL: http://jira.codehaus.org/browse/CONTINUUM-1274 Project: Continuum Issue Type: Bug Components: Integration - Maven 2, SCM Affects Versions: 1.1-alpha-1 Environment: ubunto 7.04 java 6 Reporter: Sebastian Annies Priority: Critical All release steps from update-working-copy to map-development-versions work fine. The next phase ' rewrite-poms-for-release' fails because of read-only pom.xml. this could be an issue with the scmUseEdit flag since perforce file are read-only by default. see log output: (I tried to fix alpha-2 by myself therfor log output is alpha2-SNAPSHOT, error reproduces with alpha-1, too) [INFO] Updating local copy against the scm... [INFO] Verifying that there are no local modifications... [INFO] Checking dependencies and plugins for snapshots ... [ERROR] org.apache.maven.shared.release.ReleaseExecutionException: Error writing POM: /home/drmtest/continuum-1.1-alpha-2-SNAPSHOT/continuum-webapp/src/main/webapp/WEB-INF/working-directory/1/pom.xml (Permission denied) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:659) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:604) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:190) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:115) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.execute(AbstractRewritePomsPhase.java:98) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) at org.apache.maven.shared.release.DefaultReleaseManager.prepareWithResult(DefaultReleaseManager.java:107) at org.apache.maven.continuum.release.executors.PrepareReleaseTaskExecutor.execute(PrepareReleaseTaskExecutor.java:43) at org.apache.maven.continuum.release.executors.AbstractReleaseTaskExecutor.executeTask(AbstractReleaseTaskExecutor.java:67) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:987) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:528) at java.lang.Thread.run(Thread.java:619) Caused by: java.io.FileNotFoundException: /home/drmtest/continuum-1.1-alpha-2-SNAPSHOT/continuum-webapp/src/main/webapp/WEB-INF/working-directory/1/pom.xml (Permission denied) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:179) at java.io.FileOutputStream.init(FileOutputStream.java:131) at java.io.FileWriter.init(FileWriter.java:73) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:640) ... 14 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1274) Release Project fails due to pom.xml not writable with perforce as SCM
Release Project fails due to pom.xml not writable with perforce as SCM -- Key: CONTINUUM-1274 URL: http://jira.codehaus.org/browse/CONTINUUM-1274 Project: Continuum Issue Type: Bug Components: Integration - Maven 2, SCM Affects Versions: 1.1-alpha-1 Environment: ubunto 7.04 java 6 Reporter: Sebastian Annies Priority: Critical All release steps from update-working-copy to map-development-versions work fine. The next phase ' rewrite-poms-for-release' fails because of read-only pom.xml. this could be an issue with the scmUseEdit flag since perforce file are read-only by default. see log output: (I tried to fix alpha-2 by myself therfor log output is alpha2-SNAPSHOT, error reproduces with alpha-1, too) [INFO] Updating local copy against the scm... [INFO] Verifying that there are no local modifications... [INFO] Checking dependencies and plugins for snapshots ... [ERROR] org.apache.maven.shared.release.ReleaseExecutionException: Error writing POM: /home/drmtest/continuum-1.1-alpha-2-SNAPSHOT/continuum-webapp/src/main/webapp/WEB-INF/working-directory/1/pom.xml (Permission denied) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:659) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:604) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:190) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:115) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.execute(AbstractRewritePomsPhase.java:98) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) at org.apache.maven.shared.release.DefaultReleaseManager.prepareWithResult(DefaultReleaseManager.java:107) at org.apache.maven.continuum.release.executors.PrepareReleaseTaskExecutor.execute(PrepareReleaseTaskExecutor.java:43) at org.apache.maven.continuum.release.executors.AbstractReleaseTaskExecutor.executeTask(AbstractReleaseTaskExecutor.java:67) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:987) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:528) at java.lang.Thread.run(Thread.java:619) Caused by: java.io.FileNotFoundException: /home/drmtest/continuum-1.1-alpha-2-SNAPSHOT/continuum-webapp/src/main/webapp/WEB-INF/working-directory/1/pom.xml (Permission denied) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:179) at java.io.FileOutputStream.init(FileOutputStream.java:131) at java.io.FileWriter.init(FileWriter.java:73) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:640) ... 14 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
