Any clear step by step example of how to use the maven-release-plugin with the Jazz SCM provider?

 Yes I have read this article - several times and have -DworkingDirectory set to /tmp/maven.  The command hangs and there is nothing in /tmp/maven/  I have simple parent/child code examples that are flat and another that is nested - same result.

If it's hanging, this should be reported as a bug.  Which version of RTC are you using? Does it hang in Maven (before launching the SCM CLI) or during the launch of the SCM CLI? Can you send a kill 3 to the java process(es) to get stack dumps? 

I have created a PMR - 12232,7TD,000 and I will add more to it later today.  I am using RTC 5.0.0 on Windows 7 , server and client.  I am also using Maven 3.2.3.  There is no Jazz engine involved - I am executing locally on my Windows 7 client machine.

The -DworkingDirectory=blah can point to anywhere, so long as it does not point to within the same sandbox. This is due to the jazz restruction of no nested sandboxes (that may have been lifted now).

Simple, from your project, make a dir, cd to it and do a scm load, if it does not allow nested sandboxes, then it will fail.

Are you saying that with 'https://' in the <server> section that it was hanging, or did it fail with a connection or auth error? 

 I executed this in a Windows command line.   I looked like it was was waiting for something.  There was no authentication error.  Eventually I Ctrl-C'd the process.

Don't flatten it, leave it as nested. If you're on 5.0.2, you'll have a version of eclipse that can cope with linked projects, so unless you're using WID/IID, you'll be fine.

As for work items. Once I get through the pain of upgrading the DB to 4.0, then I'll be able to address the need to associate work items with changesets.

 I have cleaned up my example and have the prepare step working.  I temporarily changed the process to remove the restriction.  It seems strange that the provide doe snot support attaching a work item since work items are central, a release would be something interesting to track, that there is a Track Build Item,etc.  Should I create the enhancement - there are few others I have though of like providing filters on Jenkins jobs in the Hudson/Jenkins Build Definition.

Yes, please go ahead and create the enhancement for allowing a work item to be specified / created. Regarding publishing on jazz.net, the wiki is restricted to developers, but it's possible to publish an article in the jazz.net/library. Could track this in a work item too, with review by someone on the Build team.

 The distributionManagement section of the pom (or settings.xml) is fundamental to the maven release process. release:perform checks out the previous tag (ie what was created in the release:prepare phase) and then spawns a "mvn deploy" on it. This is the standard maven release process and is documented everywhere (there is nothing jazz specific about it, is the point that I'm trying to make here).

 The current snapshot version of both the release plugin and the scm providers now provides the ability to supply a WI to allow the deliver command to work.

The error here is about the URL, not specifically about the project layout, but I believe the driving release plugin (not our extension to it) may make assumptions about the URL structure based on the project layout.

The pom scm URLs are modified by the prepare process.  The issue is the project structure is flat and something is getting confused.  The solution provided at https://jazz.net/forum/questions/156938/maven-scm-plugin-bug-with-flat-structure

 See below

Don't flatten it. ever.

Why do you wish to do so?

You've got to remember, that maven uses an abstraction layer to represent all SCM operations across all SCM implementations, of which Jazz is one.

It's not a very thing abstraction layer, as it natually represents the history of it's own development, namely cvs -> svn -> git.

Maven does a single checkout for the entire prepare process, using the ONE url from the base pom.xml. Use a nested structure and make sure that everything is under that.

For clarity I recommend that the name in pom.xml is the same as the Jazz Component name - it's clearer. I use the name from the base/root pom to build up the snapshot names.

Sorry, artifactId, not the name.

One thing to mention here is release:prepare when operating on a nested project creates a repository workpsace with the artifact-version format (parent-0.0.3) whereas with a flat project it doesn't do so

So, here you're saying that it works correctly, when nested.
And fails when not.
There's your answer. :) Do not flatten.

The reports about the release plugin working with a flattened structure have been that it's very hit and miss. So your milage will vary. Simply put, I do not recommend it.