date:20150331


[ 
https://jira.codehaus.org/browse/SCM-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365895#comment-365895
 ] 

Chris Graham commented on SCM-725:
--

I've investigated this. It is actually an error in the release plugin/manager. 
It never calls the unlock scm apis.
Congratulations. You're the first person on the planet to use this 
functionality! :)

I've created [https://jira.codehaus.org/browse/MRELEASE-904] to track.

This issue is not specific to the jazz provider, it applies to all providers as 
it's all called from the release plugin. That is where it needs to be fixed.


 Failure to unlock pom.xml on RTC server after release:perform
 -

 Key: SCM-725
 URL: https://jira.codehaus.org/browse/SCM-725
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-jazz
Affects Versions: 1.7, 1.8, 1.8.1
 Environment: Windows 7 on client workstation
 RTC 4.0.1
Reporter: Oscar Picasso

 1- configured maven-release-plugin with   
 useEditModetrue/useEditMode
 2- mvn release:prepare = the pom.xml is locked on the RTC server
 3- mvn release:perform = the pom.xml is still locked on the RTC server. It 
 should not.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SCM-795) scm output parsing is too agressive on stderr

Chris Graham created SCM-795:


 Summary: scm output parsing is too agressive on stderr
 Key: SCM-795
 URL: https://jira.codehaus.org/browse/SCM-795
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-jazz
Affects Versions: 1.9.2
 Environment: All.
Reporter: Chris Graham


In some versions of the jazz client (scm.exe), which is a wrapper for a 
headless eclipse runtime, there are some additional lines output to stderr 
(about a JobManager still running or similar) but the scm.exe return code is 
zero.

The parsing code is being too aggressive as it detects stderr output and 
assumes (incorrectly in this case) an error. The return code should take 
priority over the stderr output (which really should be ignored).



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SCM-724) pushChanges not working with maven-scm-provider-jazz


[ 
https://jira.codehaus.org/browse/SCM-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365892#comment-365892
 ] 

Chris Graham commented on SCM-724:
--

Hi All.

The base jazz code has not changed much, so it will continue to produce the 
same results.

If it's still happening, could you please run mvn -X release:prepare 
release:perform?

That will dump the execution of the scm commands to the console log.

Then it's a matter of working out what commands are failing (and why). You also 
need to confirm that the scm deliver is being executed.

Does the release (excluding the scm issues here) complete successfully? Or does 
it fail with an error.

 pushChanges not working with maven-scm-provider-jazz
 

 Key: SCM-724
 URL: https://jira.codehaus.org/browse/SCM-724
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-jazz
Affects Versions: 1.7, 1.8, 1.8.1
 Environment: Client on windows 7
 Jazz RTC version 4.0.1 (for server and scm)
Reporter: Oscar Picasso

 1- maven-release-plugin configured with pushChangestrue/pushChanges
 2- the RTC repository workspace for the releases has a default/current stream 
 as target flow
 2- execute
 mvn release:prepare release:perform
 After release completion:
 - changes performed on the RTC repository workspace are not delivered to the 
 target stream
 - the ownership of the RTC snapshot created during the release has not been 
 changed to the target stream
 According to the documentation it seems the changes should be propagated to 
 the target stream.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SCM-790) Jazz SCM: Support branch creation


[ 
https://jira.codehaus.org/browse/SCM-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365893#comment-365893
 ] 

Chris Graham commented on SCM-790:
--

Hi. Now that V3 is EOL'd, I can look at this. Realistically, would you use 
this, or are you better off using the UI to perform the necessary work. I'll 
look at it and see what it needed to implement it (and if any extra params are 
needed).

 Jazz SCM: Support branch creation
 -

 Key: SCM-790
 URL: https://jira.codehaus.org/browse/SCM-790
 Project: Maven SCM
  Issue Type: Improvement
  Components: maven-scm-provider-jazz
Reporter: Martin E
Priority: Minor

 Implement the branching command by creating a stream.
 This feature is not implemented yet because (as stated in 
 JazzBranchCommand.java) the scm command doesn't support stream creation.
 But since RTC 4 it is possibe to create streams... (see 
 http://www-01.ibm.com/support/knowledgecenter/SSYMRC_4.0.5/com.ibm.team.scm.doc/topics/create_stream.html)



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-1024) verify goal ignores dependenciesToScan parameter when checking tests existence

2015-03-31 Thread Sebastian Paul (JIRA)


[ 
https://jira.codehaus.org/browse/SUREFIRE-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365894#comment-365894
 ] 

Sebastian Paul edited comment on SUREFIRE-1024 at 3/31/15 3:12 AM:
---

For the impatient, simply unpack the tests as workaround:

{code:xml|title=pom.xml}
plugin
!-- due to https://jira.codehaus.org/browse/SUREFIRE-1024 --
!-- we have to unpack the tests --
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
version2.10/version
executions
execution
idunpack-tests/id
goals
goalunpack-dependencies/goal
/goals
configuration

includeArtifactIdstests-jar/includeArtifactIds

includes**/IT*.class,**/*IT.class,**/*ITCase.class/includes

outputDirectory${project.build.testOutputDirectory}/outputDirectory
/configuration
/execution
/executions
/plugin
{code}


was (Author: sebpaul):
For the unpatient, simply unpack the tests as workaround:

{code:xml|title=pom.xml}
plugin
!-- due to https://jira.codehaus.org/browse/SUREFIRE-1024 --
!-- we have to unpack the tests --
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
version2.10/version
executions
execution
idunpack-tests/id
goals
goalunpack-dependencies/goal
/goals
configuration

includeArtifactIdstests-jar/includeArtifactIds

includes**/IT*.class,**/*IT.class,**/*ITCase.class/includes

outputDirectory${project.build.testOutputDirectory}/outputDirectory
/configuration
/execution
/executions
/plugin
{code}

 verify goal ignores dependenciesToScan parameter when checking tests 
 existence
 --

 Key: SUREFIRE-1024
 URL: https://jira.codehaus.org/browse/SUREFIRE-1024
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Failsafe Plugin
Affects Versions: 2.16
Reporter: Dmitry Kholodilov
 Fix For: 3.0

 Attachments: 
 verify_goal_ignores_dependenciesToScan_parameter_when_checking_tests_existence.patch


 Consider Maven project with packaging=pom that executes tests from some 
 external jar:
 {code:xml}
 project xmlns=http://maven.apache.org/POM/4.0.0; 
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 
 http://maven.apache.org/xsd/maven-4.0.0.xsd;
 modelVersion4.0.0/modelVersion
 groupIdtest/groupId
 artifactIdtest/artifactId
 versiontest/version
 packagingpom/packaging
 dependencies
 dependency
 groupIdtest/groupId
 artifactIdtests-jar/artifactId
 version1.0/version
 classifiertests/classifier
 /dependency
 dependency
 groupIdorg.testng/groupId
 artifactIdtestng/artifactId
 version6.8/version
 /dependency
 /dependencies
 build
 plugins
 plugin
 artifactIdmaven-failsafe-plugin/artifactId
 version2.17-SNAPSHOT/version
 configuration
 dependenciesToScan
 dependencytest:tests-jar/dependency
 /dependenciesToScan
 /configuration
 executions
 execution
 idintegration-test/id
 phaseintegration-test/phase
 goals
 goalintegration-test/goal
 /goals
 /execution
 execution
 idverify/id
 phaseverify/phase
 goals
 goalverify/goal
 /goals
 /execution
 /executions
 /plugin
 /plugins
 /build
 /project
 {code}
 (real use case is execution of prebuilt end-to-end tests of some system after 
 its deployment)
 When

[jira] (SCM-725) Failure to unlock pom.xml on RTC server after release:perform


[ 
https://jira.codehaus.org/browse/SCM-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365895#comment-365895
 ] 

Chris Graham edited comment on SCM-725 at 3/31/15 3:20 AM:
---

I've investigated this. It is actually an error in the release plugin/manager. 
It never calls the unlock scm apis.
Congratulations. You're the first person on the planet to use this 
functionality! :)

I've created [https://jira.codehaus.org/browse/MRELEASE-904] to track.

This issue is not specific to the jazz provider, it applies to all providers as 
it's all called from the release plugin. That is where it needs to be fixed.

As such, this issue should probably be closed as 'not a bug'.



was (Author: chrisgwarp):
I've investigated this. It is actually an error in the release plugin/manager. 
It never calls the unlock scm apis.
Congratulations. You're the first person on the planet to use this 
functionality! :)

I've created [https://jira.codehaus.org/browse/MRELEASE-904] to track.

This issue is not specific to the jazz provider, it applies to all providers as 
it's all called from the release plugin. That is where it needs to be fixed.


 Failure to unlock pom.xml on RTC server after release:perform
 -

 Key: SCM-725
 URL: https://jira.codehaus.org/browse/SCM-725
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-jazz
Affects Versions: 1.7, 1.8, 1.8.1
 Environment: Windows 7 on client workstation
 RTC 4.0.1
Reporter: Oscar Picasso

 1- configured maven-release-plugin with   
 useEditModetrue/useEditMode
 2- mvn release:prepare = the pom.xml is locked on the RTC server
 3- mvn release:perform = the pom.xml is still locked on the RTC server. It 
 should not.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SCM-725) Failure to unlock pom.xml on RTC server after release:perform


 [ 
https://jira.codehaus.org/browse/SCM-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anders Hammar updated SCM-725:
--

Fix Version/s: 1.9.5

 Failure to unlock pom.xml on RTC server after release:perform
 -

 Key: SCM-725
 URL: https://jira.codehaus.org/browse/SCM-725
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-jazz
Affects Versions: 1.7, 1.8, 1.8.1
 Environment: Windows 7 on client workstation
 RTC 4.0.1
Reporter: Oscar Picasso
 Fix For: 1.9.5


 1- configured maven-release-plugin with   
 useEditModetrue/useEditMode
 2- mvn release:prepare = the pom.xml is locked on the RTC server
 3- mvn release:perform = the pom.xml is still locked on the RTC server. It 
 should not.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] [Commented] (MPOM-64) Change maven-source-goal from jar to jar-no-fork

2015-03-31 Thread Stevo Slavic (JIRA)


[ 
https://issues.apache.org/jira/browse/MPOM-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14388207#comment-14388207
 ] 

Stevo Slavic commented on MPOM-64:
--

Are there plans to release this any time soon?

 Change maven-source-goal from jar to jar-no-fork
 

 Key: MPOM-64
 URL: https://issues.apache.org/jira/browse/MPOM-64
 Project: Maven POMs
  Issue Type: Improvement
  Components: asf
Affects Versions: ASF-16
Reporter: Karl Heinz Marbaise
Assignee: Karl Heinz Marbaise
Priority: Minor
 Fix For: ASF-17






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] (SUREFIRE-1024) verify goal ignores dependenciesToScan parameter when checking tests existence

2015-03-31 Thread Sebastian Paul (JIRA)


[ 
https://jira.codehaus.org/browse/SUREFIRE-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365894#comment-365894
 ] 

Sebastian Paul commented on SUREFIRE-1024:
--

For the unpatient, simply unpack the tests as workaround:

{code:title=pom.xml}
plugin
!-- due to https://jira.codehaus.org/browse/SUREFIRE-1024 --
!-- we have to unpack the tests --
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
version2.10/version
executions
execution
idunpack-tests/id
goals
goalunpack-dependencies/goal
/goals
configuration

includeArtifactIdstests-jar/includeArtifactIds

includes**/IT*.class,**/*IT.class,**/*ITCase.class/includes

outputDirectory${project.build.testOutputDirectory}/outputDirectory
/configuration
/execution
/executions
/plugin
{code}

 verify goal ignores dependenciesToScan parameter when checking tests 
 existence
 --

 Key: SUREFIRE-1024
 URL: https://jira.codehaus.org/browse/SUREFIRE-1024
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Failsafe Plugin
Affects Versions: 2.16
Reporter: Dmitry Kholodilov
 Fix For: 3.0

 Attachments: 
 verify_goal_ignores_dependenciesToScan_parameter_when_checking_tests_existence.patch


 Consider Maven project with packaging=pom that executes tests from some 
 external jar:
 {code:xml}
 project xmlns=http://maven.apache.org/POM/4.0.0; 
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 
 http://maven.apache.org/xsd/maven-4.0.0.xsd;
 modelVersion4.0.0/modelVersion
 groupIdtest/groupId
 artifactIdtest/artifactId
 versiontest/version
 packagingpom/packaging
 dependencies
 dependency
 groupIdtest/groupId
 artifactIdtests-jar/artifactId
 version1.0/version
 classifiertests/classifier
 /dependency
 dependency
 groupIdorg.testng/groupId
 artifactIdtestng/artifactId
 version6.8/version
 /dependency
 /dependencies
 build
 plugins
 plugin
 artifactIdmaven-failsafe-plugin/artifactId
 version2.17-SNAPSHOT/version
 configuration
 dependenciesToScan
 dependencytest:tests-jar/dependency
 /dependenciesToScan
 /configuration
 executions
 execution
 idintegration-test/id
 phaseintegration-test/phase
 goals
 goalintegration-test/goal
 /goals
 /execution
 execution
 idverify/id
 phaseverify/phase
 goals
 goalverify/goal
 /goals
 /execution
 /executions
 /plugin
 /plugins
 /build
 /project
 {code}
 (real use case is execution of prebuilt end-to-end tests of some system after 
 its deployment)
 When we run `mvn clean verify` on such project, failsafe plugin's verify 
 goal reports the following:
 {noformat}
 [INFO] --- maven-failsafe-plugin:2.16:verify (verify) @ test ---
 [INFO] No tests to run.
 {noformat}
 Consequently, even if there are test failures, build success is reported.
 The reason of such behavior is that VerifyMojo ignores dependenciesToScan 
 parameter. So, the fix is easy - check its existence along with 
 testClassesDirectory existence, the same way as implemented in 
 AbstractSurefireMojo.
 The patch in attachment includes integration test that checks for build 
 failure when there is failed test from dependency jar.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MRELEASE-904) scm unedit is never called when useEditMode = true

Chris Graham created MRELEASE-904:
-

 Summary: scm unedit is never called when useEditMode = true
 Key: MRELEASE-904
 URL: https://jira.codehaus.org/browse/MRELEASE-904
 Project: Maven Release Plugin
  Issue Type: Bug
  Components: scm
Affects Versions: 2.5.1
Reporter: Chris Graham
Priority: Trivial


When useEditMode = true is set, all files that need to be locked (via 
scm-edit) are locked. However, scm-unedit is never called to release the 
locks.

ref: [https://jira.codehaus.org/browse/SCM-725]



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SCM-724) pushChanges not working with maven-scm-provider-jazz


 [ 
https://jira.codehaus.org/browse/SCM-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anders Hammar updated SCM-724:
--

Fix Version/s: 1.9.5

 pushChanges not working with maven-scm-provider-jazz
 

 Key: SCM-724
 URL: https://jira.codehaus.org/browse/SCM-724
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-jazz
Affects Versions: 1.7, 1.8, 1.8.1
 Environment: Client on windows 7
 Jazz RTC version 4.0.1 (for server and scm)
Reporter: Oscar Picasso
 Fix For: 1.9.5


 1- maven-release-plugin configured with pushChangestrue/pushChanges
 2- the RTC repository workspace for the releases has a default/current stream 
 as target flow
 2- execute
 mvn release:prepare release:perform
 After release completion:
 - changes performed on the RTC repository workspace are not delivered to the 
 target stream
 - the ownership of the RTC snapshot created during the release has not been 
 changed to the target stream
 According to the documentation it seems the changes should be propagated to 
 the target stream.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SCM-725) Failure to unlock pom.xml on RTC server after release:perform


 [ 
https://jira.codehaus.org/browse/SCM-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anders Hammar updated SCM-725:
--

Fix Version/s: (was: 1.9.5)

 Failure to unlock pom.xml on RTC server after release:perform
 -

 Key: SCM-725
 URL: https://jira.codehaus.org/browse/SCM-725
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-jazz
Affects Versions: 1.7, 1.8, 1.8.1
 Environment: Windows 7 on client workstation
 RTC 4.0.1
Reporter: Oscar Picasso

 1- configured maven-release-plugin with   
 useEditModetrue/useEditMode
 2- mvn release:prepare = the pom.xml is locked on the RTC server
 3- mvn release:perform = the pom.xml is still locked on the RTC server. It 
 should not.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SCM-795) scm output parsing is too aggressive on stderr


 [ 
https://jira.codehaus.org/browse/SCM-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Graham updated SCM-795:
-

Summary: scm output parsing is too aggressive on stderr  (was: scm output 
parsing is too agressive on stderr)

 scm output parsing is too aggressive on stderr
 --

 Key: SCM-795
 URL: https://jira.codehaus.org/browse/SCM-795
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-jazz
Affects Versions: 1.9.2
 Environment: All.
Reporter: Chris Graham

 In some versions of the jazz client (scm.exe), which is a wrapper for a 
 headless eclipse runtime, there are some additional lines output to stderr 
 (about a JobManager still running or similar) but the scm.exe return code is 
 zero.
 The parsing code is being too aggressive as it detects stderr output and 
 assumes (incorrectly in this case) an error. The return code should take 
 priority over the stderr output (which really should be ignored).



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SCM-796) Improve internal and user level documentation for the jazz provider

Chris Graham created SCM-796:


 Summary: Improve internal and user level documentation for the 
jazz provider
 Key: SCM-796
 URL: https://jira.codehaus.org/browse/SCM-796
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-jazz
Affects Versions: 1.9.2
 Environment: N/A
Reporter: Chris Graham
Priority: Trivial


Update the internal java doc for the scm commands, referencing the V5 releases.

Update the user level documentation, expanding and clarifying the usage of, and 
best practices for the maven jazz provider.




--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SCM-724) pushChanges not working with maven-scm-provider-jazz


 [ 
https://jira.codehaus.org/browse/SCM-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anders Hammar updated SCM-724:
--

Fix Version/s: (was: 1.9.5)

 pushChanges not working with maven-scm-provider-jazz
 

 Key: SCM-724
 URL: https://jira.codehaus.org/browse/SCM-724
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-jazz
Affects Versions: 1.7, 1.8, 1.8.1
 Environment: Client on windows 7
 Jazz RTC version 4.0.1 (for server and scm)
Reporter: Oscar Picasso

 1- maven-release-plugin configured with pushChangestrue/pushChanges
 2- the RTC repository workspace for the releases has a default/current stream 
 as target flow
 2- execute
 mvn release:prepare release:perform
 After release completion:
 - changes performed on the RTC repository workspace are not delivered to the 
 target stream
 - the ownership of the RTC snapshot created during the release has not been 
 changed to the target stream
 According to the documentation it seems the changes should be propagated to 
 the target stream.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SCM-775) Request for new optional parameter RTC (workItem) with release:prepare to associate workitem with changesets got created during build process


 [ 
https://jira.codehaus.org/browse/SCM-775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl-Heinz Marbaise updated SCM-775:


Fix Version/s: 1.9.5

 Request for new optional parameter RTC (workItem) with release:prepare to 
 associate workitem with changesets got created during build process
 -

 Key: SCM-775
 URL: https://jira.codehaus.org/browse/SCM-775
 Project: Maven SCM
  Issue Type: Improvement
  Components: maven-scm-provider-jazz
Affects Versions: 1.9.1
Reporter: AShit Shah
 Fix For: 1.9.5


 Maven {{release:prepare}} command is failing with below error while 
 delivering updated pom.xml to the stream due to Preconditions configured in 
 RTC to have comments and associated work item with every delivery. 
 {noformat}
 [ERROR] Name: Deliver
 [ERROR] Participant Reports:
 [ERROR] Name: Require Work items and Comments
 [ERROR] A work item must be associated with the change set.`
 [ERROR] At least one of the associated work items must specify that the work 
 is planned for the current iteration.
 [ERROR] At least one of the associated work items must be assigned to you.
 [ERROR] Problem running 'deliver':
 [ERROR] 'Deliver' failed. Preconditions have not been met: A work item must 
 be associated with the change set.
 [ERROR] - [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-release-plugin:2.5:prepare (default-cli) 
 on project junit-ext: Unable to commit files
 Provider message:
 Error code for Jazz SCM deliver command - 17
 {noformat}
 I can not find any optional parameters on 
 http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html 
 for release:prepare command which I can use and pass the RTC workitem number 
 on command line.
 Suggestion:
 It will be great if you can provide optional parameters like workItem which 
 I can use and pass RTC workitem number with release:prepare at command line.
 Example: {{mvn -PmyProfile release:prepare -DworkItem=123456}}
 So build process should associate change sets created by {{release:prepare}} 
 with work item 123456 and deliver change sets to the stream.
 As of now I have to use {{-DpushChanges=false}} parameter to block delivery 
 process and I have to manually find the change sets, associate them with work 
 item and deliver them before I run {{release:perform}}.
 Thanks.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SCM-725) Failure to unlock pom.xml on RTC server after release:perform


 [ 
https://jira.codehaus.org/browse/SCM-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl-Heinz Marbaise updated SCM-725:


Fix Version/s: 1.9.5

 Failure to unlock pom.xml on RTC server after release:perform
 -

 Key: SCM-725
 URL: https://jira.codehaus.org/browse/SCM-725
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-jazz
Affects Versions: 1.7, 1.8, 1.8.1
 Environment: Windows 7 on client workstation
 RTC 4.0.1
Reporter: Oscar Picasso
 Fix For: 1.9.5


 1- configured maven-release-plugin with   
 useEditModetrue/useEditMode
 2- mvn release:prepare = the pom.xml is locked on the RTC server
 3- mvn release:perform = the pom.xml is still locked on the RTC server. It 
 should not.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SCM-724) pushChanges not working with maven-scm-provider-jazz


 [ 
https://jira.codehaus.org/browse/SCM-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl-Heinz Marbaise updated SCM-724:


Fix Version/s: 1.9.5

 pushChanges not working with maven-scm-provider-jazz
 

 Key: SCM-724
 URL: https://jira.codehaus.org/browse/SCM-724
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-jazz
Affects Versions: 1.7, 1.8, 1.8.1
 Environment: Client on windows 7
 Jazz RTC version 4.0.1 (for server and scm)
Reporter: Oscar Picasso
 Fix For: 1.9.5


 1- maven-release-plugin configured with pushChangestrue/pushChanges
 2- the RTC repository workspace for the releases has a default/current stream 
 as target flow
 2- execute
 mvn release:prepare release:perform
 After release completion:
 - changes performed on the RTC repository workspace are not delivered to the 
 target stream
 - the ownership of the RTC snapshot created during the release has not been 
 changed to the target stream
 According to the documentation it seems the changes should be propagated to 
 the target stream.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SCM-795) scm output parsing is too aggressive on stderr


 [ 
https://jira.codehaus.org/browse/SCM-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl-Heinz Marbaise updated SCM-795:


Fix Version/s: 1.9.5

 scm output parsing is too aggressive on stderr
 --

 Key: SCM-795
 URL: https://jira.codehaus.org/browse/SCM-795
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-jazz
Affects Versions: 1.9.2
 Environment: All.
Reporter: Chris Graham
 Fix For: 1.9.5


 In some versions of the jazz client (scm.exe), which is a wrapper for a 
 headless eclipse runtime, there are some additional lines output to stderr 
 (about a JobManager still running or similar) but the scm.exe return code is 
 zero.
 The parsing code is being too aggressive as it detects stderr output and 
 assumes (incorrectly in this case) an error. The return code should take 
 priority over the stderr output (which really should be ignored).



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MRELEASE-851) javaHome is ignored and inherited unexpected

2015-03-31 Thread Robert Scholte (JIRA)

[
https://jira.codehaus.org/browse/MRELEASE-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Robert Scholte updated MRELEASE-851:

Description:
The release: mojos have a configuration {{javaHome}} which defaults to
$\{java.home}. From reading the documentation it seems like this is used to
propagate the JAVA version of the marent process to the invoked build of
prepare and perform. This inheritance is important in order to properly support
compiles. The documentation does not mention that the option is ignored.

The following proposed patch might be able to solve the problem by setting the
JAVA_HOME variable as documented. This also helps some situations where CI
servers not reliable replicate builds.

The patch does not include it, but most likely it should also be noted that
{{MAVEN_SKIP_RC=true}} should be added to the child's env.

https://github.com/apache/maven-release/pull/5

was:
The release: mojos have a configuration javaHome which defaults to
${java.home}. From reading the documentation it seems like this is used to
propagate the JAVA version of the marent process to the invoked build of
prepare and perform. This inheritance is important in order to properly support
compiles. The documentation does not mention that the option is ignored.

The following proposed patch might be able to solve the problem by setting the
JAVA_HOME variable as documented. This also helps some situations where CI
servers not reliable replicate builds.

The patch does not include it, but most likely it should also be noted that
MAVEN_SKIP_RC=true should be added to the child's env.

https://github.com/apache/maven-release/pull/5

javaHome is ignored and inherited unexpected

Key: MRELEASE-851
URL: https://jira.codehaus.org/browse/MRELEASE-851
Project: Maven Release Plugin
Issue Type: Bug
Affects Versions: 2.4.1
Reporter: Bernd Eckenfels
Labels: github-pullrequest

The release: mojos have a configuration {{javaHome}} which defaults to
$\{java.home}. From reading the documentation it seems like this is used to
propagate the JAVA version of the marent process to the invoked build of
prepare and perform. This inheritance is important in order to properly
support compiles. The documentation does not mention that the option is
ignored.
The following proposed patch might be able to solve the problem by setting
the JAVA_HOME variable as documented. This also helps some situations where
CI servers not reliable replicate builds.
The patch does not include it, but most likely it should also be noted that
{{MAVEN_SKIP_RC=true}} should be added to the child's env.
https://github.com/apache/maven-release/pull/5

--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SCM-790) Jazz SCM: Support branch creation