Steve,

I was able to modify the sample Maven project in the MavenBuild wiki topic to use the SCM CLI at the end of the compile phase to checkin and deliver an added file, generated from a directory listing.

I added the my-app project to Jazz Source Control, then edited the build definition's configuration to add the Jazz Source Control participant, pointing to a build workspace (with the stream as its flow target, as usual).

I then added the exec plugin to the pom.xml (under the project / build / plugins element), with 3 executions to create the file, check it in, then deliver the new change set to the stream.

		<plugin>

		    <groupId>org.codehaus.mojo</groupId>

		    <artifactId>exec-maven-plugin</artifactId>

		    <version>1.1</version>

		    <executions> 

		        <execution>

		            <id>listing</id>

		            <phase>compile</phase>

		            <goals>

		                <goal>exec</goal>

		            </goals>

				    <configuration>

				        <executable>ls</executable>

				        <arguments>

				            <argument>-al</argument>

				        </arguments>

			            <outputFile>output.txt</outputFile>

				    </configuration>

		        </execution>

		        <execution>

		            <id>checkin</id>

		            <phase>compile</phase>

		            <goals>

		                <goal>exec</goal>

		            </goals>

				    <configuration>

				        <executable>/Users/nedgar/Work/RTC-3.0-M5/jazz/scmtools/eclipse/scm.sh</executable>

				        <arguments>

				            <argument>--non-interactive</argument>

				            <argument>checkin</argument>

				            <argument>output.txt</argument>

				            <argument>-u</argument>

				            <argument>${userId}</argument>

				            <argument>-P</argument>

				            <argument>${password}</argument>

				        </arguments>

				    </configuration>

		        </execution>

		        <execution>

		            <id>deliver</id>

		            <phase>compile</phase>

		            <goals>

		                <goal>exec</goal>

		            </goals>

				    <configuration>

				        <executable>/Users/nedgar/Work/RTC-3.0-M5/jazz/scmtools/eclipse/scm.sh</executable>

				        <arguments>

				            <argument>--non-interactive</argument>

				            <argument>deliver</argument>

				            <argument>-u</argument>

				            <argument>${userId}</argument>

				            <argument>-P</argument>

				            <argument>${password}</argument>

				        </arguments>

				    </configuration>

		        </execution>

		    </executions>

		</plugin>

I'm using the scm.sh shell script since I'm running on a Mac, which can't run the executable directly. On Windows or Linux, you should change this to scm or lscm (lscm runs the SCM CLI as a daemon, reducing startup time significantly).

I made the following changes to the Maven page of the build definition:

Project location: ${loadDir}/my-app 

Goals: -e clean install

Java VM arguments: -DrepositoryAddress={a test repository URL} -DuserId=nedgar -Dpassword={my password}

The loadDir property was defined on the Properties page (set to /Users/nedgar/Work/fetched), and also used in the Jazz Source Control page. The -e argument in the Goals field (which also supports non-goal arguments) is for richer error feedback.

The userId and password properties are passed to Maven, since I didn't want to hardwire these into the POM, particularly since it's checked into SCM. They could have just as well gone in the Goals field, since Maven also processes -D as a program argument.

The repositoryAddress property isn't used in this example, since it can infer the repository when the SCM CLI is run from within the load directory for subcommands like checkin and deliver, but it is needed for some other subcommands (e.g. list snapshots). The -u argument isn't strictly needed for the same reason. The -P argument can be avoided by manually logging in to the repository from the build machine using the same credentials as used to run JBE, and telling it to cache the password when prompted:

scm login -r {repository URL} -u {user id} -c

(enter password when prompted)

You can also specify the password directly:

scm login -r {repository URL} -u {user id} -P {password}

But the prompted approach avoids the password showing up in your shell command history.

When running scm from a script like this, it's important to specify --non-interactive so that it doesn't hang waiting for input (such as for a password prompt).

I hope this helps clarify how the SCM CLI can be used together with Maven, all driven by RTC Build.

Regards,
Nick

Steve,

have you looked into the command line interface? I believe you could use that to do some of the things you requested.

Ralph

Hello,

Does anyone has an idea how RTC can deal with code changes whenever the build execution script (in this case Maven) makes changes to the sources?

Is there a way that RTC, after execution of Maven, takes again control to check-in and deliver those changes before creating the baseline?

The only solution we have for the moment is to create a plugin in Maven that connects to RTC API.

Thanks for your feedback,
Steve

Ralph,

As far as I know, it is what Steve is talking about when he speaks about a plugin in Maven... The plugin will actually have to use the Jazz SCM CLI.

Steve, it might be interesting for the thread to explain what you can already directly with Maven when you are connected to SVN instead of RTC.
Thx

You could use the Java client API to do so (no need to build your own),
but the command line was designed to make this kind of thing simple,
so that's what I'd suggest trying first.

Cheers,
Geoff

stevewillems wrote:

I see what you mean. Instead of piloting Maven from RTC it would be
done command line, since there exists some. Afterwards use command
line access to do te necessary in RTC before giving the command back
to the JBE.

Philippe, what I wanted to avoid is yet another plugin to be developed
inside Maven to communicate with RTC to to checkin/deliver/baseline
etc, like maven is now capable of doing with svn.
I would like to leave this out of maven also because I want to do this
also for other non maven applications.

Ralf,
Do you propose to access RTC commandline or to build a small java
interface application that willl be called for accessing RTC?

Thanks,
Steve

Hi Steve,

the CLI already has commands you could use. I assume if there are no restrictions that would prevent you from achieving your goals it would be easiest to use e.g. if at all possible call to it from the POM (I don't know if that is possible in Maven 8-)). If you could do that you could even stay with using the Maven tab in the build definition. You would simply try to deliver the chages as one step of the build and do a snapshot afterwards. Usinh ant Tasks would hopefully allow to add the data you want to the RTC Build Result too.

If that is not possible a plugin or a plain java library java program would be the choice. However I would expect that to be more work.

Ralph

I see what you mean. Instead of piloting Maven from RTC it would be done command line, since there exists some. Afterwards use command line access to do te necessary in RTC before giving the command back to the JBE.

Philippe, what I wanted to avoid is yet another plugin to be developed inside Maven to communicate with RTC to to checkin/deliver/baseline etc, like maven is now capable of doing with svn.
I would like to leave this out of maven also because I want to do this also for other non maven applications.

Ralf,
Do you propose to access RTC commandline or to build a small java interface application that willl be called for accessing RTC?

Thanks,
Steve

I've updated the Maven entry in the Build FAQ to refer to this example:
https://jazz.net/wiki/bin/view/Main/BuildFAQ#MavenSupport

How can I chain up actions in order to get successive builds, like we can have with TeamCity or Hudson ?

Here's the process i'd like to execute
1-Continuous build (i already have this build working)
2-on build success, copy sources on a remote filesystem
3-on copy success, call a remote batch by url invocation

Any help would be appreciated !

Guillaume, you can use the requestTeamBuild Ant task to have one build kick off another one, passing any extra properties needed via a properties file specified with the overridePropertiesFile= attribute. The file can be generated with <echo> invocations. Please see the Ant task reference in the Help for more details.