Maven SCM Plugin for RTC
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
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
Hi Sandor,
No, the source is not currently available.
That, in and of itself will not help you, as you'll need to have some corresponding changes made to the release plugin as well. I documented the exact nature of these required changes earlier in this thread.
You've said above, that the build fails at an earlier point. Can you please run mvn with the -X switch and either email me the results (if too big) or post here. I'm really curious as to why it would be failing at an earlier point.
Also, could you please try putting the jazz_xxx variables that you are currently passing in via the command line (and via -Darguments) into the properties section of your settings.xml and see if they are still being passed through? For example:
etc.
That is another means of passing things through to mvn (just make sure that it is in an active profile!)
If in doubt, then run this:
And of course, to see how everything is being resolved, use:
Looking forward to seeing the output from -X.
-Chris
No, the source is not currently available.
That, in and of itself will not help you, as you'll need to have some corresponding changes made to the release plugin as well. I documented the exact nature of these required changes earlier in this thread.
You've said above, that the build fails at an earlier point. Can you please run mvn with the -X switch and either email me the results (if too big) or post here. I'm really curious as to why it would be failing at an earlier point.
Also, could you please try putting the jazz_xxx variables that you are currently passing in via the command line (and via -Darguments) into the properties section of your settings.xml and see if they are still being passed through? For example:
<properties>
<jazz_user>me</jazz_user>
<jazz_password>pwd</jazz_password>
</properties>
etc.
That is another means of passing things through to mvn (just make sure that it is in an active profile!)
If in doubt, then run this:
mvn org.apache.maven.plugins:maven-help-plugin:2.1:system
And of course, to see how everything is being resolved, use:
mvn help:effective-pom
Looking forward to seeing the output from -X.
-Chris
Hi,
Is it possible to download the sources for jazz scm provider maven plugin?
Where?
How?
Thanks,
Sandor
I just realised that I had not posted all of the example code that I used to test this.
The sample pom.xml above, references the file: zip-for-release-no-deps.xml, and here it is:
The sample pom.xml above, references the file: zip-for-release-no-deps.xml, and here it is:
<?xml version='1.0' encoding='UTF-8'?>
<assembly>
<id>bin</id>
<formats>
<format>zip</format>
</formats>
<includeBaseDirectory>true</includeBaseDirectory>
<dependencySets>
<dependencySet>
<useTransitiveDependencies>false</useTransitiveDependencies>
<useProjectArtifact>false</useProjectArtifact>
</dependencySet>
</dependencySets>
</assembly>
Hi Sandor. We're working towards getting the source for the Jazz SCM provider contributed to Apache Maven project. Chris has the latest source, and has offered to help broker the source to Apache.
Chris, in the meantime, I'm fine with you sending Sandor the source, with any fixes you've applied.
Chris, in the meantime, I'm fine with you sending Sandor the source, with any fixes you've applied.
Just a quick update from me.
I have successfully integrated the jazz scm code into the 1.7-SNAPSHOT release. NOTE: It is not in the Apache SVN. It means that I've got it working locally.
I have successfully modified the jazz source so that it can now work with the release plugin to obtain username/password from the user's settings.xml.
This means that the username and password are now optional in the pom! This will ease a lot of people's issues with audits!
Next up. Getting the check out command to work with tags/branches (ie snapshots. Not sure how we'll do streams for branches though).
-Chris
I have successfully integrated the jazz scm code into the 1.7-SNAPSHOT release. NOTE: It is not in the Apache SVN. It means that I've got it working locally.
I have successfully modified the jazz source so that it can now work with the release plugin to obtain username/password from the user's settings.xml.
This means that the username and password are now optional in the pom! This will ease a lot of people's issues with audits!
Next up. Getting the check out command to work with tags/branches (ie snapshots. Not sure how we'll do streams for branches though).
-Chris
Now a question from me.
How do people expect the tagging (snapshots) to work.
By that I mean, when we perform a release in SVN etc, we end up with a tag. One that is permanently and publicly visable to all.
This is the behaviour that I would like to preserve.
So, at the moment, we create the snapshot using:
scm create snapshot --repository-uri https://rtc:9444/jazz --username Deb --password Deb --name BogusTestJazz-3.0.0.29 --description " copy for tag BogusTestJazz-3.0.0.29" BogusRepositoryWorkspace
What I'd like to do, is to immediately follow this up with a create workspace, so that we can then check out the workspace in the release:perform phase.
Using the example above, this is how I'd do it:
scm create workspace BogusTestJazz-3.0.0.29 --repository-uri https://rtc:9444/jazz --username Deb --password Deb --snapshot BogusTestJazz-3.0.0.29
That gives us a workspace the same name as the snapshot. Which makes sense to me.
How do others feel about this?
And, given that we are distributed, like git, how to I deliver these changes via the scm command?
The scm plugin, since v1.4, has a 'push' option, defaulted to true, to push commit changes to upstream repo. From what I understand, this is a deliver operation. The push can be disabled if need be.
How would I deliver the above changes?
How do people expect the tagging (snapshots) to work.
By that I mean, when we perform a release in SVN etc, we end up with a tag. One that is permanently and publicly visable to all.
This is the behaviour that I would like to preserve.
So, at the moment, we create the snapshot using:
scm create snapshot --repository-uri https://rtc:9444/jazz --username Deb --password Deb --name BogusTestJazz-3.0.0.29 --description " copy for tag BogusTestJazz-3.0.0.29" BogusRepositoryWorkspace
What I'd like to do, is to immediately follow this up with a create workspace, so that we can then check out the workspace in the release:perform phase.
Using the example above, this is how I'd do it:
scm create workspace BogusTestJazz-3.0.0.29 --repository-uri https://rtc:9444/jazz --username Deb --password Deb --snapshot BogusTestJazz-3.0.0.29
That gives us a workspace the same name as the snapshot. Which makes sense to me.
How do others feel about this?
And, given that we are distributed, like git, how to I deliver these changes via the scm command?
The scm plugin, since v1.4, has a 'push' option, defaulted to true, to push commit changes to upstream repo. From what I understand, this is a deliver operation. The push can be disabled if need be.
How would I deliver the above changes?
Today's update:
The passwords are now masked. As in svn style, any password will be shown in the log as '*****', eg:
The passwords are now masked. As in svn style, any password will be shown in the log as '*****', eg:
[INFO] Executing: cmd.exe /X /C "scm status --username Deb --password ***** --wide"
[INFO] Working directory: C:\CALMData\Workspaces\RTC\Deb\BogusTest
We can now use the maven release plugin with the jazz provider.
Chris,
Awesome work! Well done. Can you expand upon your announcement?
Does this mean the long (a little quirky) process you outlined in #51 is not needed and the standard release plugin will work as is?
Looking forward to an official release of this sometime in the near future.
Scott
Hi Scott.
It means we are now a lot closer, and a lot less quirky, to geting a more 'normal' maven release process working.
I needed to add a single class to the release manager/plugin. This class writes the SCM section in the pom.xml file as the release occurs. We need to do this to allow the pom to be modified from the current working remote workspace to the name of the snapshot that is created. The name of the created workspace is the usual maven ${artifactId}-${version}.
I have also modified the base jazz scm provider to recognise the tag (snapshot) so that it will check out the tag (snapshot) as a part of the release:perform process. Previously, this was not happening - it was always checking out the current working remote workspace, not the tag/snapshot!
They were the minimum changes that needed to be done to support the release process.
These changes have been done.
I have also started adding a new more usability things.
1. I now mask the password in the command line output.
2. The "err -" line is now only shown when there is an error - to remove confusion.
3. We can now make use of username/password when a server entry is present in the user's settings.xml file. This will be the biggest gain for people who do not want their userid/password stored in the pom for audit reasons.
4. I've added a few more JUnit test cases.
5. I've fixed some of the old non-working ones.
On my to do list.
1. Tidy things up.
2. Complete the incomplete/unimplemented scm functions.
3. Improve the internal comments/structure of the code as necessary.
4. Provide a really good few pages of web site information, documenting how it's all used (this will be produced by the mvn site command and is what is published on the scm site.
Like this:
http://maven.apache.org/scm/maven-scm-providers/maven-scm-provider-accurev/index.html
and not:
http://maven.apache.org/scm/maven-scm-providers/maven-scm-provider-clearcase/index.html
What needs to happen, irrespective of how much above occurs:
1. I need to finish whatever I am going to do.
2. Create a patch, so it can be included into the 1.7-SNAPSHOT SCM code.
3. Get the maven commiters etc to vote to release it.
4. Create a patch for the JazzScmTranslator to include in the maven release code.
5. Get the maven release code updated to include the released 1.7 SCM code that includes the Jazz code.
6. Get the maven commiters etc to vote to release it (2.2.3).
I have no idea of what timeframe it will take to get all of that done. Especially as some of it is in the hands of others.
We can use bits of it now, with additional configuration of the scm and release plugins - BUT WITHOUT THE POM rewriting. That code has to be embedded into the release manager. The work arounds for that have been listed well above in this thread.
-Chris
Chris,
Awesome work! Well done. Can you expand upon your announcement?
Does this mean the long (a little quirky) process you outlined in #51 is not needed and the standard release plugin will work as is?
Looking forward to an official release of this sometime in the near future.
Scott
It means we are now a lot closer, and a lot less quirky, to geting a more 'normal' maven release process working.
I needed to add a single class to the release manager/plugin. This class writes the SCM section in the pom.xml file as the release occurs. We need to do this to allow the pom to be modified from the current working remote workspace to the name of the snapshot that is created. The name of the created workspace is the usual maven ${artifactId}-${version}.
I have also modified the base jazz scm provider to recognise the tag (snapshot) so that it will check out the tag (snapshot) as a part of the release:perform process. Previously, this was not happening - it was always checking out the current working remote workspace, not the tag/snapshot!
They were the minimum changes that needed to be done to support the release process.
These changes have been done.
I have also started adding a new more usability things.
1. I now mask the password in the command line output.
2. The "err -" line is now only shown when there is an error - to remove confusion.
3. We can now make use of username/password when a server entry is present in the user's settings.xml file. This will be the biggest gain for people who do not want their userid/password stored in the pom for audit reasons.
4. I've added a few more JUnit test cases.
5. I've fixed some of the old non-working ones.
On my to do list.
1. Tidy things up.
2. Complete the incomplete/unimplemented scm functions.
3. Improve the internal comments/structure of the code as necessary.
4. Provide a really good few pages of web site information, documenting how it's all used (this will be produced by the mvn site command and is what is published on the scm site.
Like this:
http://maven.apache.org/scm/maven-scm-providers/maven-scm-provider-accurev/index.html
and not:
http://maven.apache.org/scm/maven-scm-providers/maven-scm-provider-clearcase/index.html
What needs to happen, irrespective of how much above occurs:
1. I need to finish whatever I am going to do.
2. Create a patch, so it can be included into the 1.7-SNAPSHOT SCM code.
3. Get the maven commiters etc to vote to release it.
4. Create a patch for the JazzScmTranslator to include in the maven release code.
5. Get the maven release code updated to include the released 1.7 SCM code that includes the Jazz code.
6. Get the maven commiters etc to vote to release it (2.2.3).
I have no idea of what timeframe it will take to get all of that done. Especially as some of it is in the hands of others.
We can use bits of it now, with additional configuration of the scm and release plugins - BUT WITHOUT THE POM rewriting. That code has to be embedded into the release manager. The work arounds for that have been listed well above in this thread.
-Chris
We can now use the maven release plugin with the jazz provider.
Chris,
Awesome work! Well done. Can you expand upon your announcement?
Does this mean the long (a little quirky) process you outlined in #51 is not needed and the standard release plugin will work as is?
Looking forward to an official release of this sometime in the near future.
Scott
page 7of 11 pages