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
The code necessary to support workItem (scm associate changeset) has been delivered to the apache SCM git repo and the release plugin SVN repo.
I have additional changes and updates and testing to make, but the basis of the code is now there, for those of you who can not wait for a formal release of the maven-release and maven-scm code. :) -Chris |
I am having a lot of trouble configuring my pom to get the SCM Jazz plugin to work (I've already posted a question to that extent).
Do you by any chance have a working example using the plugin that I would be able to examine?
|
Has there been any thought/work on porting the SCM Plugin to use the native Java RTC Api instead of deferring to the command-line client?
Comments
Chris Graham
commented Apr 14 '15, 8:20 p.m.
Yes, and the answer is definately NO.
|
I appologize if this is not the correct forum to post this question, but there is something missing in the Jazz-SCM maven plugin documentation plugin on https://maven.apache.org/scm/maven-scm-providers/maven-scm-provider-jazz/index.html.
Under the section `Flow Targets`, the documentation reads:
A deliver or accept operates between a repository workspace and its flow target, normally a stream but could also be another repository workspace . The promote is used toCan someone please fill in the blank? A `promote` is used to ... what? Comments
Chris Graham
commented Apr 13 '15, 9:30 p.m.
Hmmm. A very good question!
Chris Graham
commented Apr 13 '15, 9:43 p.m.
Nope. Looking at the history, I never finished the sentence, and you're the first one to pick it up. Thanks!
|
So if my thinking is correct. All instances similar to:
// Now that we have a list of files to process, we can "add" (scm checkin) them. JazzAddConsumer addConsumer = new JazzAddConsumer( repo, getLogger() ); ErrorConsumer errConsumer = new ErrorConsumer( getLogger() ); JazzScmCommand command = createAddCommand( repo, fileSet ); int status = command.execute( addConsumer, errConsumer ); if ( status != 0 || errConsumer.hasBeenFed() ) { return new AddScmResult( command.getCommandString(), "Error code for Jazz SCM add (checkin) command - " + status, errConsumer.getOutput(), false ); } return new AddScmResult( command.getCommandString(), addConsumer.getFiles() );Will become: // Now that we have a list of files to process, we can "add" (scm checkin) them. JazzAddConsumer addConsumer = new JazzAddConsumer( repo, getLogger() ); ErrorConsumer errConsumer = new ErrorConsumer( getLogger() ); JazzScmCommand command = createAddCommand( repo, fileSet ); int status = command.execute( addConsumer, errConsumer ); if ( status != 0 ) { return new AddScmResult( command.getCommandString(), "Error code for Jazz SCM add (checkin) command - " + status, errConsumer.getOutput(), false ); } return new AddScmResult( command.getCommandString(), addConsumer.getFiles() );Which is consistent with the other providers (that I checked). |
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.
|
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.
|
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:
|
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.
|
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 |
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.