Trouble configuring Maven SCM plugin for RTC

Eric Benzacar (41●10●12) | asked Apr 16 '15, 1:21 p.m.
edited Apr 16 '15, 1:27 p.m.

I'm struggling at getting the Maven SCM plugin for RTC properly configured in my pom. My goal is to use the maven-release-plugin, but at the moment, I'm just trying to validate that I have the SCM properly configured. In my pom, I have the following:

And a corresponding <server> entry in my settings.xml with id scm-dev.domain.local.

<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>

However, when I try a simple command `mvn scm:status` I get the following error:

[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

If I try `mvn scm:list` I get a different error code:

[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.

Is my setup incorrect, or am I misunderstanding how to use this plugin?

4 answers

Most liked answers ↑|Newest answers|Oldest answers

permanent link

Chris Graham (367●9●14) | answered Apr 16 '15, 10:41 p.m.

Hi.

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

Eric Benzacar commented Apr 17 '15, 1:37 p.m.

I didn't want to pollute the main thread (general questions) with specifics like this, but did try to link to it.

I agree - my first step is to get the SCM working, which is why I was trying something simple like scm:list or scm:status. And getting 54 or 1 as error msgs isn't telling me much unfortuntately. I did find an exit code guide here but both error codes don't tell me much as to where the original problem is.

Could the issue be related to my repo being an HTTPS repo with a self-signed certificate? But I would have expected to see an HTTPS error in the stack trace (for which there is none)

Eric Benzacar commented Apr 21 '15, 3:12 p.m.

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.

Chris Graham commented Apr 21 '15, 7:25 p.m.

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.

permanent link

Chris Graham (367●9●14) | answered Apr 17 '15, 7:19 p.m.

From your sandbox, what is the output of "SCM status", don't edit it, just paste it all here.

When running release:prepare are you adding the -D to point to a different location?

What version of RTC are you using?

Comments

Eric Benzacar commented Apr 21 '15, 3:16 p.m. | edited Apr 21 '15, 3:17 p.m.

I'm using RTC 4.0.2, and running into some more frustrations. I don't know if there is anyway around my issue.

At the moment, if I have my RTC client (RAD) opened, I cannot seem to run any scm commands:

$ scm status

Problem 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

Which means that every time I want to do anything, I have to close eclipse, run a test, and then re-open eclipse to make changes. Quite a pain.

Is there anything I can do to avoid this headache? Running mvn release:prepare and having it fail b/c files are modified, then having to re-open eclipse to make the changes, close eclipse, re-run mvn release:prepare, etc, is not a functional workflow.

Chris Graham commented Apr 21 '15, 7:32 p.m.

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.

permanent link

Eric Benzacar (41●10●12) | answered Apr 21 '15, 3:59 p.m.

I'm also running into a fairly big limitation right now in that we have an operation behaviour requiring a work item to be assigned to a change set upon deliver. Is there anyway to have the plugin do something like that if we preconfigure which work item to assign?

Is there someway I can fork just the jazz-scm plugin and modify it and tell maven to use a different version of the jazz-scm plugin, or do I have to fork the entire scm plugin to accomplish something like that?

Comments

Chris Graham commented Apr 21 '15, 7:43 p.m.

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. :(

permanent link

Eric Benzacar (41●10●12) | answered Apr 22 '15, 10:27 a.m.
edited Apr 22 '15, 10:28 a.m.

I just noticed something that seems a little odd. My release-plugin failed due to the WorkItem issue (as mentioned above); given SCM-775, that's expected behaviour.

But when I looked at my pom, I noticed that the release plugin modified more than just my pom version information. It also modified my <scm> data:

Originally was:

<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>

However it was changed to:

<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>

As you can see, the connection/developerConnection/url details have had their definitions change to reflect the artifactId-version. This seems unexpected. Or is this normal/expected behaviour?

Comments

Chris Graham commented Apr 22 '15, 10:15 p.m. | edited Apr 22 '15, 10:20 p.m.

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:

    
    <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.

Chris Graham commented Apr 22 '15, 10:24 p.m.

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"

Eric Benzacar commented Apr 23 '15, 12:09 p.m.

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?

Chris Graham commented Apr 23 '15, 6:11 p.m.

I'm still waiting on a full -X execution log. Please email it to me privately if needed.

Eric Benzacar commented Apr 23 '15, 10:00 p.m.

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.

Your answer

Register or log in to post 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.

It's all about the answers!

Related questions

Trouble configuring Maven SCM plugin for RTC

4 answers

Your answer