Trouble configuring Maven SCM plugin for RTC
<scm><connection>scm:jazz:https://scm-dev.domain.local/ccm:DEV-build-Management-Release plugin POC Workspace</connection><developerConnection>scm:jazz:https://scm-dev.domain.local/ccm:DEV-build-Management-Release plugin POC Workspace</developerConnection><url>https://scm-dev.domain.local/ccm</url></scm>
[INFO] --- maven-scm-plugin:1.9.4:status (default-cli) @ release_poc-parent ---[INFO] Executing: cmd.exe /X /C "scm status --username bene007 --password ***** --wide"[INFO] Working directory: C:\dev\Eclipse\maven_versioning_poc\release_poc\release_poc-parent[ERROR] Provider message:[ERROR] Error code for Jazz SCM status command - 54
[INFO] --- maven-scm-plugin:1.9.4:list (default-cli) @ release_poc-parent ---[INFO] Executing: cmd.exe /X /C "scm status --username bene007 --password ***** --wide"[INFO] Working directory: C:\dev\Eclipse\maven_versioning_poc\release_poc\release_poc-parent[INFO] Executing: cmd.exe /X /C "scm list remotefiles --repository-uri https://scm-dev.domain.local/ccm --username ben007 --password ***** "DEV-build-Management-Release plugin POC Workspace""[INFO] Working directory: C:\dev\Eclipse\maven_versioning_poc\release_poc\release_poc-parent[ERROR] Error: Argument syntax error:Missing arguments to subcommand "list remotefiles" - component, remotePath. Try 'scm help list remotefiles' for more information.
4 answers
Interesting errors. None that I've seen before, either by me or reported to me.
Firstly, what version are you using? You should also try running mvn release:prepare with -X (mvn -X release:prepare). That will give you the debug output which will also include all of the raw output from the calls to "scm.exe ..."
Here is a section of the pom.xml that I used to test all of my releases whilst developing the plugin:
<!-- Specify the SCM settings. Used as part of the release process to create tags etc. -->
<scm>
<url>https://rtc:9444/jazz:GPDBWorkspace</url>
<connection>scm:jazz:https://rtc:9444/jazz:GPDBWorkspace</connection>
<developerConnection>scm:jazz:https://rtc:9444/jazz:GPDBWorkspace</developerConnection>
</scm>
The thing that you need to remember, is that maven is just a wrapper for the underling SCM being used, be it SVN, Git, TFS or as in this case RTC.
So, when push comes to shove, we need to get the underling scm command working correctly, once they are working, then it's a matter of me getting the plugin to call them correctly.
Ah, good I see that you've posted on the main question thread. It's best to keep the main thread of questions/answers there.
I'm in the process of upgrading the RTC VM that I have, from V3.0.0 to 3.0.1.6 Ifix 5 (done) to 4.0 and all point releases to 5.0.2, so I can now easily track issues specific to any particular versions.
So your timing is good! :)
-Chris
Comments
I didn't want to pollute the main thread (general questions) with specifics like this, but did try to link to it.
After a bunch of failed trial and error attempts, I finally decided to change the workspace name to something without spaces and it seems to work. Either that, or manually performing an scm login first seems to have unlocked my access issues.
Heh. Never try two changes at once. :)
In this case, the "scm login" first should stop the unable to find the repo errors. Personally, I do not like workspaces etc with spaces in them, however, I'm pretty sure that I tested for that and suitably quoted everything that needs it.
Comments
I'm using RTC 4.0.2, and running into some more frustrations. I don't know if there is anyway around my issue.
$ scm statusProblem running 'status':Could not initialize data area. Another RCP application is running in this sandbox. File locked at file:C:\dev\Eclipse\maven_versioning_poc
The "Another RCP app" error is a pure jazz issue - not a maven one. You can not have two jazz clients connected to the same workspace at once.
Have you seen? Working with the release plugin
The GPDBBuildWorkspace and FireDragonBuildWorkspace are the only places that you should run the release plugin, not your local dev workspace. Those workspaces should have been called GPDBReleaseWorkspace to make it clearer, and in the next release of the jazz provider it will be.
In your case, you should be delivering the changes to the stream or release workspace. You can not run a release (with any maven scm) when you have files that are under source control that have been modified, so performing a deliver is a good way to ensure that.
Comments
Don't bother forking. The reason that I'm working though all of the upgrade pain at the moment is to work though all of the versions of RTC and fix the issues that are specific to RTC releases.
And the work item issue is the one with the highest priority: SCM-775
4.0.2 introduced a LOT of breaking changes (heavy internal refactoring - some of which was too aggressive and did not work).
At least with 4.0.2 the "scm login" workaround works. It does not with 4.0. :(
<groupId>com.dom.poc</groupId><artifactId>release_poc-parent</artifactId><version>0.0.1-SNAPSHOT</version><packaging>pom</packaging><name>release_poc-parent</name><scm><connection>scm:jazz:https://scm-dev.dom.local/ccm:DEV-test</connection><developerConnection>scm:jazz:https://scm-dev.dom.local/ccm:DEV-test</developerConnection><url>https://scm-dev.dom.local/ccm:DEV-test</url></scm>
<groupId>com.dom.poc</groupId><artifactId>release_poc-parent</artifactId><version>0.0.1</version><packaging>pom</packaging><name>release_poc-parent</name><scm><connection>scm:jazz:https://scm-dev.dom.local/ccm:release_poc-parent-0.0.1</connection><developerConnection>scm:jazz:https://scm-dev.dom.local/ccm:release_poc-parent-0.0.1</developerConnection><url>https://scm-dev.dom.local/ccm:release_poc-parent-0.0.1</url></scm>
Comments
No, that is totally normal. The URL's are rewritten so that they point to the tag location. If you look closely, you will now have a release_poc_parent-0.0.1 workspace.
Here are the details from one of my released projects, it's been rewritten in the same manner:
<!-- Specify the SCM settings. Used as part of the release process to create tags etc. -->
<scm>
<url>https://rtc:9444/jazz:GPDB-1.0.10</url>
<connection>scm:jazz:https://rtc:9444/jazz:GPDB-1.0.10</connection>
<developerConnection>scm:jazz:https://rtc:9444/jazz:GPDB-1.0.10</developerConnection>
</scm>
If you've ever done releases before, using svn or similar (don't look at git, as it does not rewrite them), you'll see that the scm section is similarly rewritten.
When the release process completes successfully, you'll see that the scm section urls are put back to their originals.
This is what happens:
1. The pom version is rewritten to be NON SNAPSHOT, and the SCM URLs changed.
2. The pom(s) are committed.
3. A tag/Jazz SNAPSHOT is taken at that point.
4. The pom is rewritten again, the version is (N+1)-SNAPSHOT and the SCM URL's are returned to their original state.
5. The pom(s) are committed again.
These are the steps that the release:prepare performed (as well as others).
The release:perform simply reads some properties files that are left over from the release (to work out what it just did), check them out to a new dir, and then run "mvn deploy"
That's somewhat what I had suspected. However, I'm a bit unclear on the value as that URL doesn't actually exist and doesn't actually work (at least in my case). Or is that just something inherited from the scm plugin that can't be touched?
I'm still waiting on a full -X execution log. Please email it to me privately if needed.
Sorry - I never bothered sending you a -X log as I had managed to make it work finally (getting rid of those strange exit code errors). Please let me know if you still want it, and I will email a log to you.