Build engine does not support Solaris

To install RTC 3.0 we have to run IM on Solaris via sudo as root.
Furthermore the installed packages are not committed to Solaris package manager.

Is it possible to run IM as a non root user ( with rights to write under /opt/)?

What are the best practices before and after building, regarding source and the temporary files?
Does IBM recommend to preserve the workspace and only load changes prior to the build?
What temporary files should/could be preserved, and how can we be assured that the intermediary results must not be rebuilt?
(a jar would have to be rebuilt if a contained java class has changed)

As a result of a build, we generate neutralized archives like EARs, WARs and Zip files. Currently in our environment these files are preserved in ClearCase and are used as source for deployments into the different target systems(after customization) using the baseline as key.

Where do we save the results when using RTC?

To install RTC 3.0 we have to run IM on Solaris via sudo as root.
Furthermore the installed packages are not committed to Solaris package manager.

Is it possible to run IM as a non root user ( with rights to write under /opt/)?

Hi Karen

You may want to post these entries as different questions in the forum.

re: installing - I suspect you need to have a user that has access rights (rw- to /opt to install in /opt.

regards

anthony

Hi Karen,

For the first question about the build system toolkit on Solaris, there is an open enhancement request for this feature that is in the Backlog.

http://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=118347

There is some information on running the JBE on platforms other than 32-bit Windows and Linux at the site below.

https://jazz.net/wiki/bin/view/Main/JbeOtherPlatforms

Brent Ulbricht
Developer/Lead - RTC Build

What are the best practices before and after building, regarding source and the temporary files?
Does IBM recommend to preserve the workspace and only load changes prior to the build?
What temporary files should/could be preserved, and how can we be assured that the intermediary results must not be rebuilt?
(a jar would have to be rebuilt if a contained java class has changed)

What are the best practices before and after building, regarding source and the temporary files?
Does IBM recommend to preserve the workspace and only load changes prior to the build?
What temporary files should/could be preserved, and how can we be assured that the intermediary results must not be rebuilt?
(a jar would have to be rebuilt if a contained java class has changed)

Hi Karen

The general idea with builds (from an RTC perspective) is that the "Build" user has their own workspace and (optionally) clears this out between builds. It will grab the source files from the relevant stream. It takes a snapshot of all the source so you should always be able to reproduce the builds later on.

However - most of the behaviour of the build is based on the build scripts themselves. RTC's job is to invoke them and report back results. You could preserve temp/intermediate files (leaving them in the build workspace), and use your build scripts to trigger a rebuild when dependencies are changed.

anthony

As a result of a build, we generate neutralized archives like EARs, WARs and Zip files. Currently in our environment these files are preserved in ClearCase and are used as source for deployments into the different target systems(after customization) using the baseline as key.

Where do we save the results when using RTC?

Hi Karen,

If you look at the build results for RTC and other Jazz products you will notice that the build result is stored in a folder in a separate file system location. The location is created during the build and has a unique name. The URI to the location is stored in the build result. Since it is a lot of data the build output is not stored in RTC's build result.

The data in the location can be used for automatic deployment and test etc.

Over time, only selected builds are marked as persistent and kept. Their File system location with the build output is kept also. Over time all other build results and related folders are deleted.

This approach allows to keep the interesting build results for later usage in releases. The results can be backed up etc.

The unique name and URL can be used to refer to the location.

It would be possible, for instance using the SCM command line interface, to version the build results in RTC. This would be similar to the ClearCase solution described above. It would be possible to create a snapshot/baseline on the stream.

I personally prefer the file system location and backup approach over storing the build output in the SCM system. The reason essentially is that SCM systems are designed to keep the overhead for the versions low by storing deltas. Binaries have to be stored completely and that means the footprint of the SCM database is rapidly increasing. Also binaries require a huge bandwidth to be transferred.

Ralph

Hi,

I am using a linux client. The summary description only contain the first two words of the longer summary description I actually wrote. The entire summary shows up on a windows client.

Has anyone else seen this behavior? Does anyone have a suggested fix for this problem?

Thanks,
Doug