Maven SCM Plugin for RTC
David Lafreniere (4.8k●7)
| asked Jul 20 '10, 3:41 p.m.
FORUM MODERATOR / JAZZ DEVELOPER edited Oct 06 '16, 10:24 a.m.
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 |
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 Comments
Oguzhan Ozavar
commented Jun 28 '13, 9:09 a.m.
Hi Chris,
Chris Graham
commented Jun 28 '13, 8:58 p.m.
Hey.
|
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 Comments
Chris Graham
commented Jun 28 '13, 9:06 p.m.
The changes above were not to fix the locks, they were simply unnecessary.
Chris Graham
commented Jul 06 '13, 7:36 a.m.
I'm going to recomment on my own answer:
Chris Graham
commented Mar 19 '14, 6:43 p.m.
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! :)
|
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)
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 |
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 |
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 |
Thanks for all the info and work on this Chris, it's really helpful.
Have you seen this type of error in your experience:
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.
|
Hi Nick & Chris.
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. 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 ***** So it looks like having the repository workspace loaded elsewhere is causing a conflict? Thanks for any additional help guys. -Jason Comments
Chris Graham
commented Mar 20 '14, 8:41 p.m.
I wonder what the return code of the SCM command is, when it spits out that error.
Chris Graham
commented Mar 20 '14, 11:57 p.m.
Looking at the code:
|
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
Chris Graham
commented Apr 04 '15, 7:28 a.m.
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.
|
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
Chris Graham
commented Mar 25 '14, 6:27 a.m.
Hmmm. On my test system, I've never managed to get lscm to work.
Jason MacDonald
commented Mar 25 '14, 9:27 a.m.
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.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.