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
Alright. We have success!
Of a sort. Kind of. It is workable. But it is not as smooth as the usual:
that I normally use. I've provided a very simple test project. It uses a pattern that I use quite often, namely, build a zip file of all listed dependencies. In this instance, I use only one, log4j. But the build bit of this project is not what we're interested in. We are interested in the SCM interactions with the Jazz SCM portion and the release plugin. Here is the entire pom.xml file that I've been using:
So, you can build the zip file as per a normal maven build:
As it stands, it will build: BogusTestJazz-3.0.0.29-SNAPSHOT.zip. Now we come to the good bit. The maven release processes. It works, but with a little manual intervention. The end result it the same, the maven release processes work. In this example, I have created a Jazz SCM Component, called BogusTest. The eclipse/maven project BogusTest is checked into that component as the eclipse project. I've used the artifactId as BogusTestJazz (to differentiate it from another project, BogusTestSVN - for testing purposes for reference). Firstly, we are able to execute the first stage of the maven release process:
This does all of the normal things that the release plugin does. It transforms the poms, checks them in, creates the tag, re-transforms the poms again, and then checks them back into the SCM. In this instance, a snapshot of ${artifactId}-${version} is created of the component. The version is then incremented, set back to a snapshot and then checked back in.
The important bit here is this SCM command to create the snapshot:
There is two issues here. 1. Unlike other SCM's, the label/tag/baseline is not able to be checked out directly from a component in Jazz SCM. So we help it along it's way by creating a repository based upon the snapshot. This is done via:
We now have a workspace called "BogusTestJazz-3.0.0.29" based on the "BogusTestJazz-3.0.0.29" snapshot of the original component BogusTest (yes, which really should have been called BogusTestJazz for consistency). 2. The pom.xml file has NOT had their SCM URL's transformed correctly. This is not right. I've written the appropriate JazzScmTranslator.java file that addresses this. This however, will need to be added to the maven-release-manager component, and thus commited to the apache project. It is simple, no IP here at all. A simple work around of this is to manually edit the release.properties file and change the original repository workspace in the URL lines to that of the new one. IE, we change:
to:
That is a horrible hack to work around the missing code out of the maven-release-manager. It also assists us in another issue with the maven-scm-provider-jazz plugin. The jazz provider does not honour the version parameter of the scmCheckout command so it will not create the appropriate SCM URL. By editing the release.properties file, we work around that limitation. So, after all that, it brings us to the second step in the release process, namely, "mvn release:perform". Basically, what a release:perform does is to check out the appropriate tag from the SCM and then execute "mvn deploy" goal on it. The final remaining issue, is that Jazz, like ClearCase and probably a few others, can not have (in Jazz terms) a sandbox within a sandbox. We work around that little gem, by using the -DworkingDirectory parameter to point the check out directory (load in Jazz terms) to a location outside of the existing sandbox (normally, ./target/checkout - which violates the sandbox within a sandbox limitation). So now we are ready to execute:
The -DworkingDirectory can point anywhere, just not within a sandbox. The results are as follows:
And that, warts and all, is how we can crank out Maven Releases with the existing maven-scm-provider-jazz:1.3 and the maven-release-plugin:2.2.2. :-) -Chris PS: Clearly, there is still work to be done. The jazz provider needs to be updated to allow userid/password to work from settings.xml. It would be nice if it created the workspaces based on the snapshots (so it works more like the end results of the other scms). The checkOut function needs to be able to understand the ScmVersion parameter passed to it (will also allow it to work with ScmBranches - more work here re streams) And probably lots more than I've discovered yet... :-)))) |
Hi,
Which version from RTC are You using? For me with RTC 3.0 I get:
Thanks, Sandor Alright. We have success! |
|
Hi. I'm using 3.0.
Check your path in the SCM section of your Pom. It must be wrong as it's only passing the server name through. It needs to be the full URL to the repo. It needs more than that. See my examples above for reference. -Chris Hi, Alright. We have success! |
|
Hi.
I have the following in my scm section:
I provide the parameters from command line. Is that wrong? Hi. I'm using 3.0. Hi, Alright. We have success! |
|
Hi.
The log of the maven run is attached. It is a multi projekt maven setup.
Hi. Hi. I'm using 3.0. Hi, Alright. We have success! |
In Chris's example the output was:
In Sandor's, it was:
Note that the scmURL was OK in the first line, but then later it lost the port and context root (/ccm). But the port, 9443, actually shows up at the end of the create snapshot command. Chris, you mentioned having to tweak the actual Maven release plugin to properly handle an scm url transformation. Sounds like this might be what Sandor is hitting. |
|
I knew I should not have been responding to that at midnight, in bed, on an iPhone...
A couple of observations. 1. I've only done a single project. Not a multi module one. That should, in and of itself, not be a cause for concern. 2. I'm not sure about variable substition here, in the SCM section. My recommendation here, would be to follow standard debugging stuff here. Remove the variables for the users etc. HARD CODE IT TO TEST. The issue here is that the pom has to be read, PARSED and then written out. I'm guessing that it's having parsing issues with the ${variable} bits, even though it all otherwise appears to work. It all depends if it re-reads the pom.xml from disk or uses the fully resolved in-memory version. 3. One of the project is a superpom - with a root? My personal preference is to have the super pom as a single module, stand alone project, released and managed as a project in it's own right. It's then used via the parent section in the pom. This promotes good reuse. It's how I do it. :-) Just the usual stuff. Back it off to a simple case, get it working, and then gradually re-introduce the complexity until it fails. It might well be that there is more work to do in the SCM provider. My preference in this case, is to wait until we get the provider modified to work with the user/password from settings.xml. -Chris In Chris's example the output was: |
|
Hi,
I have replaced the properties with hardcoded values in the pom, and I still get the same problem. The scm calls before "create snapshot" are OK, but the create snapshot does not have the right syntax...
Our root module is the cg-cm-root module, the superpom is child module under the root. I general we have a lot of multi modul maven project, so I think it would be hard/not correct to version tham separately. I can try to unconfigure the child modules from the root module to see if that fix the problem...
|
|
If I remove the child projects from the modules tag in the parent pom, than it works fine.
|
|
> Chris, you mentioned having to tweak the actual Maven release plugin to properly handle an scm url transformation.
Chris, do you think this could be a factor in what Sandor is seeing? |
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.