Maven SCM Plugin for RTC
Please use this forum topic to discuss the ongoing development of the Maven SCM Plugin for RTC.
I would especially like to know how users intend to use the Maven SCM Plugin and especially the Maven Release plugin in the context of RTC.
What would really help is if you could provide a short description of what you feel each scm goal should do. (What would help even more if you could provide a sample Jazz SCM CLI line on exactly what you feel should be done).
Often difficulty occurs because we are bound to the Maven SCM Plugin framework, and the level of information supplied to us for each goal may be too little or to much in order to easily map it 1:1 to an RTC use case scenario. RTC SCM is great at being flexible for team (or even personal) use, but it also has many "things" that other traditional SCM systems do not.
Questions of discussion could be:
1. Should the checkin goal automatically create and "complete" a change set with the given message/comment every time the checkin goal is executed?. Should it also "deliver" this change set with every checkin goal? or should it just check in files to the existing change set?
2. The checkout goal allows an optional passed in ScmVersion Maven object. For example, the release-plugin calls this checkout goal in the release:perform goal and used this ScmVersion object to represent a "snapshot" which was created in the release:prepare goal. However Jazz RTC does not allow you to checkout (i.e. "load") a particular snapshot. Can we come up with an agreed upon action for this scenario?
2a. One option would be to temporarily create another repository workspace which is based on the given snapshot. This would allow the user to checkout the files properly. However one problem is that these SCM goals act against the workspace defined in the SCM URL (in the pom.xml), thus future goals such as (status or checkin) would be against the original repository workspace, and not the one we checked out of...
3. The "project structure" of Maven projects and RTC/Eclipse projects are different. Maven has the concept of "parent projects" in which entire child projects exist below a parent project, whereas in Eclipse/RTC each project generally exists at the same root level. At the surface this doesn't appear to be a problem, but some Maven users may not be able to do what they want with the Jazz SCM provider. In particular, Jazz SCM does not allow checking out a project underneath another checked out project (i.e. can't have a sandbox in a sandbox).
3a. Ex: During an initial test run of release:perform (after performing after a release:prepare), I saw that the supplied checkout directory was "<releaseProject>\target\checkout" (Which Jazz Scm cannot do).
Please see the following Wiki document for additional information.
https://jazz.net/wiki/bin/view/Main/BuildFAQ#Does_Jazz_Team_Build_support_Mav
I would especially like to know how users intend to use the Maven SCM Plugin and especially the Maven Release plugin in the context of RTC.
What would really help is if you could provide a short description of what you feel each scm goal should do. (What would help even more if you could provide a sample Jazz SCM CLI line on exactly what you feel should be done).
Often difficulty occurs because we are bound to the Maven SCM Plugin framework, and the level of information supplied to us for each goal may be too little or to much in order to easily map it 1:1 to an RTC use case scenario. RTC SCM is great at being flexible for team (or even personal) use, but it also has many "things" that other traditional SCM systems do not.
Questions of discussion could be:
1. Should the checkin goal automatically create and "complete" a change set with the given message/comment every time the checkin goal is executed?. Should it also "deliver" this change set with every checkin goal? or should it just check in files to the existing change set?
2. The checkout goal allows an optional passed in ScmVersion Maven object. For example, the release-plugin calls this checkout goal in the release:perform goal and used this ScmVersion object to represent a "snapshot" which was created in the release:prepare goal. However Jazz RTC does not allow you to checkout (i.e. "load") a particular snapshot. Can we come up with an agreed upon action for this scenario?
2a. One option would be to temporarily create another repository workspace which is based on the given snapshot. This would allow the user to checkout the files properly. However one problem is that these SCM goals act against the workspace defined in the SCM URL (in the pom.xml), thus future goals such as (status or checkin) would be against the original repository workspace, and not the one we checked out of...
3. The "project structure" of Maven projects and RTC/Eclipse projects are different. Maven has the concept of "parent projects" in which entire child projects exist below a parent project, whereas in Eclipse/RTC each project generally exists at the same root level. At the surface this doesn't appear to be a problem, but some Maven users may not be able to do what they want with the Jazz SCM provider. In particular, Jazz SCM does not allow checking out a project underneath another checked out project (i.e. can't have a sandbox in a sandbox).
3a. Ex: During an initial test run of release:perform (after performing after a release:prepare), I saw that the supplied checkout directory was "<releaseProject>\target\checkout" (Which Jazz Scm cannot do).
Please see the following Wiki document for additional information.
https://jazz.net/wiki/bin/view/Main/BuildFAQ#Does_Jazz_Team_Build_support_Mav
104 answers
"Another issue is these temporary workspaces are not being deleted after build completion (which may cause redundant disk usage and some other problems)."
That's not an issue per-se, it is somethign that you will simply have to manage yourself.
I'd not use the locks, see how you go.
-Chris
That's not an issue per-se, it is somethign that you will simply have to manage yourself.
I'd not use the locks, see how you go.
-Chris
Comments
Hi Chris,
Temporary workspaces (not the regular ones specified in the build definition) are created per build request, so that the numbers will increase fastly in a multibuild environment (like ours). Since these are called "temporary" artifacts, they should be deleted at the end of their execution context (imho). I think no one would like to manage these kind of manual workload. Locks are totally different story which I tried to explain in the next post.
ty and best regards
Hey.
You mean "release request" not a "build request", which I'm assuming that you really mean snapshot builds.
We are talking about the release plugin's usage of the Jazz SCM provider here, so I'm assuming releases.
So I've got to ask the question, why are you burning though releases so quickly?
Currently, there is no support for deleting the release workspaces (V3 could not, but perhaps V4 might, I've not checked yet) from the SCM CLI tool, which is what the jazz provder acts as a wrapper for. So, if the functionality is not supplied by SCM(.exe) then I can not do it.
So, for the moment, you will need to clean these up manually.
And, if you're burning through 400 releases (ie workspaces) per day, I'd have to ask why???
-Chris
Main reason we need useEditMode argument is to prevent a conflict scenario which would be caused by a developer delivering pom.xml changes right after an automated build starts. In our RTC-Maven configuration, it does not seem to release the acquired locks as it does in SVN. Maybe the Unedit command in the jazz provider 1.8.1 is missing some implementation...
I tried below but still locks are not released...
thanks in advance
Oguzhan
I tried below but still locks are not released...
- removing preperation goals from pom.xml (as Chris pointed)
- removing release:perform goal (to see if it still not release the locks without -DworkingDirectory parameter)
thanks in advance
Oguzhan
Comments
The changes above were not to fix the locks, they were simply unnecessary.
I've draged out the VM that I did all of the RTC/Jazz development in, so I'll see if I can recreate the issue.
I did manually test the scm edit/unedit functionality from the command line. However, I was unaware that you could lock the poms as a part of the release, so I'll see what is going on.
-Chris
I'm going to recomment on my own answer:
Upon reflection, it IS a good idea to put the preparation goals into the pom, as it provides better documentation as to how the release was prepared.
I normally simply use:
mvn -B -Dresume=false release:prepare release:perform
and have to add in -DworkingDirectory= for the jazz stuff.
So having it all in there is most probably a good thing.
-Chris
I dug deeper, and found that it's not the maven scm jazz stuff at all. It's the maven release manager. It never calls the unlock functions! So, it would apprear that you're the first person (on the planet) to use it! :)
-Chris
Hi Chris,
I am currently working on some other ALM improvements so I could not deal with that last week. We achieved our first milestone. Thank you for your comments. Do you have any suggestions on our M2 scenario?
M1 (Demo)
We aim below scenario for our second milestone (Maven builds will be included in our release management process after that)
M2 (Real development scenario)
I am currently working on some other ALM improvements so I could not deal with that last week. We achieved our first milestone. Thank you for your comments. Do you have any suggestions on our M2 scenario?
M1 (Demo)
- We are able to perform builds with autoincrementing version numbers and without locking resources.
- We are able to upload resulting packages to the nexus repository.
We aim below scenario for our second milestone (Maven builds will be included in our release management process after that)
M2 (Real development scenario)
- Fix the unlock resource issue in a custom way (Perhaps after waiting for your test results)
- Put some version number logic for parallel development streams, ie; different projects on the same app. In fact I found a buildnumber plugin but it does not support jazz scm (only svn and git). Maybe we should find a way to include the workspace name and also an auto-incremented build number (which is stored in a common path for all parallel streams) in the version number.
Oğuzhan
I would not lock the poms. From the comments I left for myself in the jazz code itself, locking is discouraged and only recommended for binaries anyway.
If you're having regular clashes in pom changes and the release plugin you need to ask yourself why this is happening.
I've found out why the locks are not being released. The release manager does not call the unedit (ie unlock) at any point in time! I need to grok that before I submit a patch.
As for parallel development, it's simple. I use the versions-plugin.
Where I'd have a branch in git or svn, I have a stream in ClearCase and Jazz.
So I have a 1.x.y.z-SNAPSHOT for the R1 stream/branch and 2.x.y.z-SNAPSHOT for the R2 stream/branch.
Yes you will get some collisions, but that can be minimised through judicious use of the versions plugin before a merge.
If you are merging from R1 -> R2 (normal, and not a R2 -> R1 backport), do this:
- Set the R2 version to the incoming R1 version on a temporary basis
- Merge in. That will cater for any other changes in the pom
- Set the R2 version back to what it was.
To use:
mvn org.codehaus.mojo:versions-maven-plugin:set -DnewVersion=#.#.#.#-SNAPSHOT
If you're having regular clashes in pom changes and the release plugin you need to ask yourself why this is happening.
I've found out why the locks are not being released. The release manager does not call the unedit (ie unlock) at any point in time! I need to grok that before I submit a patch.
As for parallel development, it's simple. I use the versions-plugin.
Where I'd have a branch in git or svn, I have a stream in ClearCase and Jazz.
So I have a 1.x.y.z-SNAPSHOT for the R1 stream/branch and 2.x.y.z-SNAPSHOT for the R2 stream/branch.
Yes you will get some collisions, but that can be minimised through judicious use of the versions plugin before a merge.
If you are merging from R1 -> R2 (normal, and not a R2 -> R1 backport), do this:
- Set the R2 version to the incoming R1 version on a temporary basis
- Merge in. That will cater for any other changes in the pom
- Set the R2 version back to what it was.
To use:
mvn org.codehaus.mojo:versions-maven-plugin:set -DnewVersion=#.#.#.#-SNAPSHOT
Hi Chris,
I think we must prevent the delivery of jar/war/ear files generated by local builds (which might result in a conflict scenario on maven side) And also the pom.xml... We can easily find someone adding dependency tags while developing a new module. Why do you think the pom should be static? Am I missing a point?
I will be reading on the versions plugin in detail, thanks for the insight. I will be reporting back the progress.
Ty
Oğuzhan
I think we must prevent the delivery of jar/war/ear files generated by local builds (which might result in a conflict scenario on maven side) And also the pom.xml... We can easily find someone adding dependency tags while developing a new module. Why do you think the pom should be static? Am I missing a point?
I will be reading on the versions plugin in detail, thanks for the insight. I will be reporting back the progress.
Ty
Oğuzhan
Have you seen this?
Working with the Release Plugin
Look at the diagrams that I created. Where you see xxxBuildWorkspace, that is the ONLY place that the maven release plugins should be used. Perhaps I should have made that clearer.
Some of what you've said makes me think that I don't think that you've fully groked the maven release process, and especially when it is to be used.
>I think we must prevent the delivery of jar/war/ear files generated by local builds (which might result in a conflict scenario on maven side)
Um no, just get local builds to do a "mvn clean install" and that will only install the built artifacts to the local maven repo. Use "mvn clean deploy" if you must, but will need to make sure that you have a snapshot repository defined in your distributionManagement section of your pom (or as I do, in a corporate parent pom).
>We can easily find someone adding dependency tags while developing a new module. Why do you think the pom should be static? Am I missing a point?
Yes, you've normally expect to see some changes in deps, but you'd only expect to see them when accepting/merging, either between release streams or with inter-developer deliver/accepts. SVN/GIT/Whatever would also have these issues.
Your comments around the build number plugin etc, make me think that you've not fully sorted this out. It should not be needed.
Are you attempting to run some form of Continuous Delivery? Where every commit is meant to be a 'release'?
-Chris
Working with the Release Plugin
Look at the diagrams that I created. Where you see xxxBuildWorkspace, that is the ONLY place that the maven release plugins should be used. Perhaps I should have made that clearer.
Some of what you've said makes me think that I don't think that you've fully groked the maven release process, and especially when it is to be used.
>I think we must prevent the delivery of jar/war/ear files generated by local builds (which might result in a conflict scenario on maven side)
Um no, just get local builds to do a "mvn clean install" and that will only install the built artifacts to the local maven repo. Use "mvn clean deploy" if you must, but will need to make sure that you have a snapshot repository defined in your distributionManagement section of your pom (or as I do, in a corporate parent pom).
>We can easily find someone adding dependency tags while developing a new module. Why do you think the pom should be static? Am I missing a point?
Yes, you've normally expect to see some changes in deps, but you'd only expect to see them when accepting/merging, either between release streams or with inter-developer deliver/accepts. SVN/GIT/Whatever would also have these issues.
Your comments around the build number plugin etc, make me think that you've not fully sorted this out. It should not be needed.
Are you attempting to run some form of Continuous Delivery? Where every commit is meant to be a 'release'?
-Chris
Thanks for all the info and work on this Chris, it's really helpful.
Have you seen this type of error in your experience:
I've seen some posts with folks hitting this error and they ignore std-error from scm, just not sure where we'd do this! The pom is updated correctly and the changeset gets created in the repository workspace, just that it can't get checked in after stoppage from the post-create-changeset error.
Have you seen this type of error in your experience:
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] BUILD SUCCESS
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Total time: 21.314s
[INFO] [INFO] Finished at: Wed Mar 19 11:52:14 EDT 2014
[INFO] [INFO] Final Memory: 20M/989M
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] Picked up _JAVA_OPTIONS: -Xmx1024m
[INFO] Checking in modified POMs...
[INFO] Executing: cmd.exe /X /C "scm create changeset --username srv-escriptscm --password ***** "[maven-release-plugin] prepare release scheduler-1.0.0-122""
[INFO] Working directory: E:\reb\KAISER\TEST_SCHEDULER\scheduler
[ERROR] Error: java.lang.IllegalStateException: Job manager has been shut down.
at org.eclipse.core.internal.jobs.JobManager.schedule(JobManager.java:1104)
at org.eclipse.core.internal.jobs.InternalJob.schedule(InternalJob.java:427)
at org.eclipse.core.runtime.jobs.Job.schedule(Job.java:462)
at com.ibm.team.filesystem.rcp.core.internal.changes.util.listeners.UpdateChangesJob.requestUpdate(UpdateChangesJob.java:151)
at com.ibm.team.filesystem.rcp.core.internal.changes.update.util.UpdateManager.requestUpdate(UpdateManager.java:77)
at com.ibm.team.filesystem.rcp.core.internal.changes.util.listeners.EventManager.handleEvents(EventManager.java:611)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$1.run(EventSource.java:720)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher.process(EventSource.java:713)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$3.run(EventSource.java:771)
at com.ibm.team.repository.client.util.ThreadCheck.runProhibitingLongOps(ThreadCheck.java:174)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher.process(EventSource.java:756)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$4.run(EventSource.java:790)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:906)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:929)
at java.lang.Thread.run(Thread.java:738)
We're using RTC 4.0.6 (4.0.5 Build toolkit) on Windows 7 (64-bit).
I've seen some posts with folks hitting this error and they ignore std-error from scm, just not sure where we'd do this! The pom is updated correctly and the changeset gets created in the repository workspace, just that it can't get checked in after stoppage from the post-create-changeset error.
Comments
This issue is being tracked in UpdateChangesJob scheduled during shutdown (217382). It occurs in a background event handler, so should have no impact on the original SCM operation, and scm.exe should exit with code 0 (OK). But in the output you posted, Maven appears to be flagging it as an ERROR anyway.
Does it cause the build to fail, or is it just unwanted output?
Hi Jason.
This is a base error from the underlying SCM tool.
What is the full, raw output of this:
E:
cd E:\reb\KAISER\TEST_SCHEDULER\scheduler
scm create changeset --username srv-escriptscm --password * "[maven-release-plugin] prepare release scheduler-1.0.0-122"
Just adjust the password.
I'd like to see the output from the scm command itself.
Ta.
-Chris
Hi Nick & Chris.
It definitely stops the build after this error :)
I tried the command from the cli and it worked:
I then went to check the repository workspace in Eclipse to ensure the changeset did indeed get created (which it did). From Eclipse, I removed the changeset and re-ran the command:
The repository workspace was loaded in Eclipse on my machine while the commands were run, so I unloaded it from my Eclipse instance and re-ran the cli command on the 'build' machine:
So it looks like having the repository workspace loaded elsewhere is causing a conflict?
Thanks for any additional help guys.
-Jason
It definitely stops the build after this error :)
I tried the command from the cli and it worked:
E:\reb\KAISER\TEST_SCHEDULER\scheduler>scm create changeset --username srv-escriptscm --password ***** "[maven-release-plugin] prepare release scheduler-1.0.0-120""Created change set (1011).
I then went to check the repository workspace in Eclipse to ensure the changeset did indeed get created (which it did). From Eclipse, I removed the changeset and re-ran the command:
E:\reb\KAISER\TEST_SCHEDULER\scheduler>scm create changeset --username srv-escriptscm --password ***** "[maven-release-plugin] prepare release scheduler-1.0.0-120"" Created change set (1012). java.lang.IllegalStateException: Job manager has been shut down.
at org.eclipse.core.internal.jobs.JobManager.schedule(JobManager.java:1104)
at org.eclipse.core.internal.jobs.InternalJob.schedule(InternalJob.java:427)
at org.eclipse.core.runtime.jobs.Job.schedule(Job.java:462)
at com.ibm.team.filesystem.rcp.core.internal.changes.util.listeners.UpdateChangesJob.requestUpdate(UpdateChangesJob.java:151)
at com.ibm.team.filesystem.rcp.core.internal.changes.update.util.UpdateManager.requestUpdate(UpdateManager.java:77)
at com.ibm.team.filesystem.rcp.core.internal.changes.util.listeners.EventManager.handleEvents(EventManager.java:611)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$1.run(EventSource.java:720)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher.process(EventSource.java:713)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$3.run(EventSource.java:771)
at com.ibm.team.repository.client.util.ThreadCheck.runProhibitingLongOps(ThreadCheck.java:174)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher.process(EventSource.java:756)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$4.run(EventSource.java:790)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:906)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:929)
at java.lang.Thread.run(Thread.java:738)
java.lang.IllegalStateException: Job manager has been shut down.
at org.eclipse.core.internal.jobs.JobManager.schedule(JobManager.java:1104)
at org.eclipse.core.internal.jobs.InternalJob.schedule(InternalJob.java:427)
at org.eclipse.core.runtime.jobs.Job.schedule(Job.java:462)
at com.ibm.team.filesystem.rcp.core.internal.changes.util.listeners.UpdateChangesJob.requestUpdate(UpdateChangesJob.java:151)
at com.ibm.team.filesystem.rcp.core.internal.changes.update.util.UpdateManager.requestUpdate(UpdateManager.java:77)
at com.ibm.team.filesystem.rcp.core.internal.changes.util.listeners.EventManager.handleEvents(EventManager.java:611)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$1.run(EventSource.java:720)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher.process(EventSource.java:713)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$3.run(EventSource.java:771)
at com.ibm.team.repository.client.util.ThreadCheck.runProhibitingLongOps(ThreadCheck.java:174)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher.process(EventSource.java:756)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$4.run(EventSource.java:790)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:906)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:929)
at java.lang.Thread.run(Thread.java:738)
E:\reb\KAISER\TEST_SCHEDULER\scheduler>
The repository workspace was loaded in Eclipse on my machine while the commands were run, so I unloaded it from my Eclipse instance and re-ran the cli command on the 'build' machine:
E:\reb\KAISER\TEST_SCHEDULER\scheduler>cd\ E:\>cd reb\KAISER\TEST_SCHEDULER\scheduler E:\reb\KAISER\TEST_SCHEDULER\scheduler>scm create changeset --username srv-escriptscm --password *****
"[maven-release-plugin] prepare release scheduler-1.0.0-120jpm""
Created change set (1014).
E:\reb\KAISER\TEST_SCHEDULER\scheduler>
So it looks like having the repository workspace loaded elsewhere is causing a conflict?
Thanks for any additional help guys.
-Jason
Comments
I wonder what the return code of the SCM command is, when it spits out that error.
Are you able to ret re-running the release with -X, which will kick maven into debug more, and produce lots more output, and you should see the parsing that I do, and hopefully shed some more light on what/why it is failing.
-Chris
Looking at the code:
https://git-wip-us.apache.org/repos/asf?p=maven-scm.git;a=blob;f=maven-scm-providers/maven-scm-provider-jazz/src/main/java/org/apache/maven/scm/provider/jazz/command/JazzScmCommand.java;h=4adf121c092ebd01fa99b6434268ecbdd4c7eb3e;hb=HEAD
Line: 167-196
public int execute( StreamConsumer out, ErrorConsumer err )
It would appear that the command is returning a non-zero error code in this case.
If this is indeed the case, it makes it very hard for me to work around.
Nick? Your thoughts?
-Chris
Here's the output with -X, thanks Chris!
[INFO] Checking in modified POMs... [DEBUG] JazzScmProvider:makeProviderScmRepository [DEBUG] Provided scm url - srv-escriptscm;******@https://som-tcapp01.******.com:9444/ccm:TEST-Scheduler_Trunk-1.0.0_Build_Workspace [DEBUG] Provided delimiter - ':' [DEBUG] Scheme - https [DEBUG] Creating JazzScmProviderRepository with the following values: [DEBUG] jazzUrl - https://som-tcapp01.*****.com:9444/ccm [DEBUG] username - srv-escriptscm [DEBUG] password - ***** [DEBUG] hostname - som-tcapp01.******.com [DEBUG] port - 9444 [DEBUG] repositoryWorkspace - TEST-Scheduler_Trunk-1.0.0_Build_Workspace [DEBUG] Executing checkin command... [INFO] Executing: cmd.exe /X /C "scm create changeset --username srv-escriptscm --password ***** "[maven-release-plugin] prepare release scheduler-1.0.0-133"" [INFO] Working directory: E:\reb\KAISER\TEST_SCHEDULER\scheduler
[DEBUG] Consumed line :Created change set (1016).
[DEBUG] ErrorConsumer.consumeLine: java.lang.IllegalStateException: Job manager has been shut down.
[DEBUG] ErrorConsumer.consumeLine: at org.eclipse.core.internal.jobs.JobManager.schedule(JobManager.java:1104)
[DEBUG] ErrorConsumer.consumeLine: at org.eclipse.core.internal.jobs.InternalJob.schedule(InternalJob.java:427)
[DEBUG] ErrorConsumer.consumeLine: at org.eclipse.core.runtime.jobs.Job.schedule(Job.java:462)
[DEBUG] ErrorConsumer.consumeLine: at com.ibm.team.filesystem.rcp.core.internal.changes.util.listeners.UpdateChangesJob.requestUpdate(UpdateChangesJob.java:151)
[DEBUG] ErrorConsumer.consumeLine: at com.ibm.team.filesystem.rcp.core.internal.changes.update.util.UpdateManager.requestUpdate(UpdateManager.java:77)
[DEBUG] ErrorConsumer.consumeLine: at com.ibm.team.filesystem.rcp.core.internal.changes.util.listeners.EventManager.handleEvents(EventManager.java:611)
[DEBUG] ErrorConsumer.consumeLine: at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$1.run(EventSource.java:720)
[DEBUG] ErrorConsumer.consumeLine: at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
[DEBUG] ErrorConsumer.consumeLine: at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher.process(EventSource.java:713)
[DEBUG] ErrorConsumer.consumeLine: at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$3.run(EventSource.java:771)
[DEBUG] ErrorConsumer.consumeLine: at com.ibm.team.repository.client.util.ThreadCheck.runProhibitingLongOps(ThreadCheck.java:174)
[DEBUG] ErrorConsumer.consumeLine: at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher.process(EventSource.java:756)
[DEBUG] ErrorConsumer.consumeLine: at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$4.run(EventSource.java:790)
[DEBUG] ErrorConsumer.consumeLine: at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:906)
[DEBUG] ErrorConsumer.consumeLine: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:929)
[DEBUG] ErrorConsumer.consumeLine: at java.lang.Thread.run(Thread.java:738)
[DEBUG] ErrorConsumer.consumeLine: java.lang.IllegalStateException: Job manager has been shut down.
[DEBUG] ErrorConsumer.consumeLine: at org.eclipse.core.internal.jobs.JobManager.schedule(JobManager.java:1104)
[DEBUG] ErrorConsumer.consumeLine: at org.eclipse.core.internal.jobs.InternalJob.schedule(InternalJob.java:427)
[DEBUG] ErrorConsumer.consumeLine: at org.eclipse.core.runtime.jobs.Job.schedule(Job.java:462)
[DEBUG] ErrorConsumer.consumeLine: at com.ibm.team.filesystem.rcp.core.internal.changes.util.listeners.UpdateChangesJob.requestUpdate(UpdateChangesJob.java:151)
[DEBUG] ErrorConsumer.consumeLine: at com.ibm.team.filesystem.rcp.core.internal.changes.update.util.UpdateManager.requestUpdate(UpdateManager.java:77)
[DEBUG] ErrorConsumer.consumeLine: at com.ibm.team.filesystem.rcp.core.internal.changes.util.listeners.EventManager.handleEvents(EventManager.java:611)
[DEBUG] ErrorConsumer.consumeLine: at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$1.run(EventSource.java:720)
[DEBUG] ErrorConsumer.consumeLine: at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
[DEBUG] ErrorConsumer.consumeLine: at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher.process(EventSource.java:713)
[DEBUG] ErrorConsumer.consumeLine: at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$3.run(EventSource.java:771)
[DEBUG] ErrorConsumer.consumeLine: at com.ibm.team.repository.client.util.ThreadCheck.runProhibitingLongOps(ThreadCheck.java:174)
[DEBUG] ErrorConsumer.consumeLine: at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher.process(EventSource.java:756)
[DEBUG] ErrorConsumer.consumeLine: at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$4.run(EventSource.java:790)
[DEBUG] ErrorConsumer.consumeLine: at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:906)
[DEBUG] ErrorConsumer.consumeLine: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:929)
[DEBUG] ErrorConsumer.consumeLine: at java.lang.Thread.run(Thread.java:738)
[ERROR] Error: java.lang.IllegalStateException: Job manager has been shut down.
at org.eclipse.core.internal.jobs.JobManager.schedule(JobManager.java:1104)
at org.eclipse.core.internal.jobs.InternalJob.schedule(InternalJob.java:427)
at org.eclipse.core.runtime.jobs.Job.schedule(Job.java:462)
at com.ibm.team.filesystem.rcp.core.internal.changes.util.listeners.UpdateChangesJob.requestUpdate(UpdateChangesJob.java:151)
at com.ibm.team.filesystem.rcp.core.internal.changes.update.util.UpdateManager.requestUpdate(UpdateManager.java:77)
at com.ibm.team.filesystem.rcp.core.internal.changes.util.listeners.EventManager.handleEvents(EventManager.java:611)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$1.run(EventSource.java:720)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher.process(EventSource.java:713)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$3.run(EventSource.java:771)
at com.ibm.team.repository.client.util.ThreadCheck.runProhibitingLongOps(ThreadCheck.java:174)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher.process(EventSource.java:756)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$4.run(EventSource.java:790)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:906)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:929)
at java.lang.Thread.run(Thread.java:738)
java.lang.IllegalStateException: Job manager has been shut down.
at org.eclipse.core.internal.jobs.JobManager.schedule(JobManager.java:1104)
at org.eclipse.core.internal.jobs.InternalJob.schedule(InternalJob.java:427)
at org.eclipse.core.runtime.jobs.Job.schedule(Job.java:462)
at com.ibm.team.filesystem.rcp.core.internal.changes.util.listeners.UpdateChangesJob.requestUpdate(UpdateChangesJob.java:151)
at com.ibm.team.filesystem.rcp.core.internal.changes.update.util.UpdateManager.requestUpdate(UpdateManager.java:77)
at com.ibm.team.filesystem.rcp.core.internal.changes.util.listeners.EventManager.handleEvents(EventManager.java:611)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$1.run(EventSource.java:720)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher.process(EventSource.java:713)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$3.run(EventSource.java:771)
at com.ibm.team.repository.client.util.ThreadCheck.runProhibitingLongOps(ThreadCheck.java:174)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher.process(EventSource.java:756)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$4.run(EventSource.java:790)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:906)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:929)
at java.lang.Thread.run(Thread.java:738)
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Skipping scheduler
[INFO] This project has been banned from the build due to previous failures.
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary: [INFO] [INFO] scheduler ......................................... FAILURE [2:03.500s] [INFO] scheduler-model ................................... SKIPPED [INFO] scheduler-service ................................. SKIPPED [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 2:08.323s [INFO] Finished at: Fri Mar 21 09:25:15 EDT 2014 [INFO] Final Memory: 19M/989M [INFO] ------------------------------------------------------------------------
Comments
Hi Jason. I know it's been a while. I'm finally working on the issue(s) that the jazz provider has started to gather over the last year or two.
I've found the code, and I think the reason for it. I was too agressive in the way that I treated and parsed the error output. In this case, we appear to have the strange case of rc=0, but there is some output on the error stream. In this case, if I see error output, I'm assuming (and this is the error) that there WAS an error. An odd edge case, I know.
So, I need to change this code:
if ( status != 0 || errConsumer.hasBeenFed() )
to simply:
if ( status != 0 )
However, I'm not convinced that I'm seeing all of the output. I'd have expected to have seen something like this in the output, somewhere:
"Error code for Jazz SCM add (checkin) command - 0".
Is this issue still occurring? If so, can you please email me the complete and unedited output from mvn -X ?
Ta.
-Chris
lscm seems to work more consistently (as asked to run from Defect 217382, dup of https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/306852) -- not sure if there's a way to pass lscm instead of scm, and whether that introduces other issues since it runs as a daemon.
Comments
Hmmm. On my test system, I've never managed to get lscm to work.
A horrible horrible hack (and it's just a guess): Can you save scm.exe, and copy lscm.exe to scm.exe and see how it goes? I'm not sure of what the differences are (or if the command line parameters are compatible).
That aside, there were some login issues with the earlier 4.x releases, can you try again with a scm login (as a standalone command before doing anything else)? Again, just a stab in the dark
-Chris
We're on the same page -- before my post I tried renaming scm.exe then creating a shortcut (then link) from scm to lscm.bat, but lscm looks like it's a wrapper around scm, so that doesn't work.
I'll try the login steps and see if that helps.
page 10of 7 pagesof 8 pagesof 9 pagesof 10 pagesof 11 pages