Due to some maintenance issues, this service has been switched in read-only mode, you can find more information about the why

and how to migrate your plugin documentation in this blogpost

Skip to end of metadata
Go to start of metadata

Plugin Information

View ClearCase UCM Plugin on the plugin site for more information.

Developed by

Sponsored by

A Praqmatic integration to ClearCase UCM, simplifying continuous integration with Jenkins.

If you use this plugin - please share your current usage of it - and read what others have achieved:

Share Your Usage of This Plugin.

About the Plugin

If you are using base ClearCase you should use the old plugin. If you are using ClearCase UCM you should use this one.

Do you wonder why there is a separate plugin for ClearCase UCM? - Please read the blog post on "The rationale behind the ClearCase UCM plugin for Jenkins CI"! Also read some of the attendees reactions on this plugin as it was presented on Jenkins User Conference in Paris, april 2012 or get into depth with pre-tested commits described in our paper on the subject.

Older versions of the plugin can be found and downloaded here

What the ClearCase UCM Plugin can do?

  • Monitor changes in your ClearCase UCM VOBs by polling for new baselines on a given stream, in a given component with a given promotion level.
  • Does not require ClearCase to be installed on the master
  • No config spec to setup! The plugin establish a snapshot view in the jobs workspace, which is self-contained an 100% compliant with all the plugin that allows you to brows the workspace from the web.
  • Either PROMOTE or REJECT the baseline given the build result, success, unstable or failure.
  • Sets the description of the individual job, listing the baseline built, the result and the new promotion level.
  • Can recommend the baseline if it is promoted.
  • Can tag the baseline with the result of each individual job, so that history and statistics are persisted, not only in Jenkins, but also in ClearCase itself.
  • Supports concurrent builds - without finding the same baseline twice even when previously started jobs are still in progress (currently only supported with one iterator per slave).
  • ClearCase MultiSite is fully supported:
    • Slaves and masters can be in different ClearCase regions and even at completely different Sites
    • Polling for Posted Deliveries is supported
  • Supports pre-tested commits by monitoring either child streams (development streams within the project) or sibling streams (integration streams in other projects) and automatically deliver into the integration stream and finally complete or cancel the deliver based on the build result.
  • Supports advanced baseline naming templates.
  • Runs on both Windows and Linux (since version 1.2)
  • ...and even a handful more of nice features.

For the impatient

Please read Get up and running with ClearCase UCM plugin for Jenkins in 11 easy steps


  • ClearCase UCM Plugin assumes that a default view storage location is available in your region (it probably is, and if it's not you can easily create one using 'cleartool mkstgloc').
  • If you want to use the 'tag' function in the post-build section, you have to set up a hyperlink type named 'tag' in your VOB (details below).
  • ClearCase Client must be installed on slaves that shall execute the build (ClearCase is not required on the master). Due to JENKINS-25342 we require ClearCase to be installed on the master.
  • We assume that all your computers have unique names in your network.


Main configuration screen for Clearcase UCM Plugin.

A short description of the configuration options are listed below

Basic settings: Stream and Component Promotion level

Essentially the plugin is looking for new baselines on a specific stream belonging to a specify stream. On top op that you have to qualify which baselines are of interest in this context by applying a Promotion Level. Only baselines found that matches all three parameters will kick off the build.

When the build ends, the promotion level will either be stepped one level up (if successful) or rejected.

If you have a configuration where you use more than one component in your foundation, you may wonder why we only left room for specifying one single component - please take the time require to read the blog post on "[The rationale behind the ClearCase UCM plugin for Jenkins CI|http://www.praqma.com/stories/ccucm]"

Basic settings: Load Modules

The plugin will automatically create a snapshot view in a folder named 'view' in the root of the job's workspace. Snapshot views can - as opposed to dynamic views - be located anywhere, which we exploit to place it inside the job's workspace. Dynamic Views can only reside on the location where your mvfs is located and that is not inside the workspace.

A lot of plugins have browsing features, that allows you to see the code in the browser, high-lighted to make a point in the context (warnings, violations, code coverage...) In order to guarantee compliancy with these type of plugins we only support snapshot views.

In general build performance is also much better in snapshot views that are hosted by the clients native file system - once they are loaded.

We us a separate view per job, per client, which allows us to reuse views in a context the only changes very little between builds. Thus you will find that once you have loaded the view the first time, the successive updates will be very fast, since deltas are guaranteed to be small.

You have a small handle of control of what load-rules are applied to the snapshot views; Either you load all the components or only the modifiable ones.

Basic settings: Recommend Baseline

If the checkbox Recommend baseline is set, a successful build will recommend the baseline that was used.

Basic settings: Make tag

When the checkbox Make tag is checked, the plugin will persist the build status in ClearCase, by writing a small summary of the status as a to-text object at the end of a hyperlink of type tag attached to the baseline.

NOTE:The if you want to use this feature then the hltype:tag should be created first

Basic settings: Set description

When Set description is checked, the build description in the left margin of the job page is updated with the details of the build. Super crisp feature! Check i out!

Advanced: Unstable jobs

Some of the features in the post build section to the plugin such as the pre-tested delivery features available in poll child and poll sibling mode, and the 'Recommend baseline' checkbox ways to make boolean decisions; complete or cancel? Recommend or not? But the outcome of a Jenkins job really has three possible states; Succes, unstable and failure. You will have to decide if the unstable state should due treated as success or failure.

Polling Modes

ClearCase UCM Plugin supports three types of polling modes.

  • Self polling
  • Child polling
  • Sibling polling
  • Rebase polling
  • Subscribe polling 

Self Mode

Self mode enables you to find baselines on the stream itself given a promotion level.

If the build is successful, the plugin can recommend the baseline and it will promote it to the next level.

If the build has failed, the plugin will demote the baseline to rejected.

About the streams created in this mode, see the advanced section.

Note that this is the only mode creating auxiliary streams.

Child and Sibling Mode

This mode enables you to find baselines on related streams of the target stream. This is either development streams of the target stream(child mode) or other integration streams having this stream as default target(sibling mode).

If the build is successful, the baseline is delivered to the target stream and you can choose to create a baseline on it. The baseline of the other stream is promoted to the next level.

The plugin can recommend the new baseline on the target stream.

If the build has failed, the plugin will demote the baseline of the other stream to rejected and no deliver activity is made, and thus no baseline is created on the target stream.

Rebase Mode

This mode. based on the selected stream will compare the set of foundation baselines for a given stream, and check to see if there are newer baselines on any of the component streams. If so, the plugin will trigger

and the target stream will be rebased to the selected baselines. 

Subscribe Mode

Special polling mode that subscribes to data about compatibility of a certain set of baselines. Currently there is only one plugin that provides information this mode. The Config Rotator plugin. 


Create baseline and baseline template

Create baseline is supported for all polling modes except Poll Self. 

The option Create baseline and Name template enables you to create a baseline on the target stream. The name template is made up of free text with optional keywords, expanding to run time variables:

  • stream - The given UCM Stream
  • project - The UCM Project
  • component - The given UCM Component
  • date - The date in yyyymmdd
  • time - The time in hhmm
  • number - The current Jenkins build number
  • user - The user created the Baseline
  • env - Get an environment variable. [env=var]
  • file - Retrieve the content of a file residing in the workspace. [file=SOME_FILE]. [file=myfile] will expand to path/to/workspace/myfile and the content of the file is used. (Only a single, short line of text is supported, and it goes without saying that the string must conform to the restrictions to characters supported in baseline names)

Keywords are enclosed in square brackets([]). For example [project][date][time] will result in the baseline myproject_20110915_1128.

The plugin's baseline naming feature is meant to run on the UCM Project's default baseline naming template just containing "basename".

Although "basename" CAN be combined with other keywords in the template - it can not be entirely omitted. It's highly recommended, that if you want to use the plugin's baseline naming strategy you reset the UCM projects naming template to it's default.

Notice that this option has no meaning for self polling or if the Create baseline option is not checked.

Latest Baseline

Like the Git and Mercurial plugins, ClearCase UCM Plugin also supports polling for the latest baseline. This means, when polling, a build is scheduled only if there's a new baseline on the stream.

To be able to poll for the latest baseline, the special promotion level ANY and self polling must must be selected in the setup.

Advanced SCM setup

  • Build Project The plugin creates a separate read/only development stream and snapshot view for every self polling job on every slave that executes the job. The stream and view is created the first time the job is executed on the slave and then reused by successive job executions. If you just go with the defaults settings the streams will be created as child streams to the integration stream in the project holding the baseline that is being built, but despite the reuse of these Jenkins related streams, there is still a tendency that you end up with a lot of extra streams on behalf of the plugin. You can remove them if you want to, but the jobs will then just create them again next time they run. In order to keep your ClearCase Project Explorer tidy we've made the option to place them in an auxiliary project made specifically for this purpose (in general, development streams must be in the same UCM project as the baselines you rebase them against , but read/only streams are considered special cases and they can live safely be in a separate project). Here's the deal: If you make a project in ClearCase named 'hudson' or 'jenkins', the plugin will put the auxiliary streams there. If you prefer another name for this specialCCUCM -related project, you can specify it in the Build project box in the 'Advanced' section
  • Tagging To be able to tag your baselines, you need to create a ClearCase hyperlink type named "tag" in each UCM project vob, that will be holdding the baselines, you can do that with the following command:
    cleartool mkhltype -shared -global -c "Supports the jenkins CCUCM plugin" tag@<some_vob>
  • Do not remove the view private files By default the view private files are removed from the workspace every time a build is executed. This can be avoided by unchecking "Remove view private files".
  • Trimming the change log This is only useful in poll-self mode, and will filter off changes from contributing activities.

Build a specific baseline with a parameterized build

Parameterizing your build with a string called baseline will let you build a specific named baseline. This baseline name is the value of the parameter. This feature will let you have one job, that does the polling on SCM and then has a post-build step orchestrated by the Parameterized Trigger Plugin which builds the same baseline. The downstream job, should have the same settings for stream and component - and if you set the promotion level to ANY, the downstream job will not change the built baseline's promotion level.

Build variables

The ClearCase UCM plugin introduces several build variables:

  • CC_BASELINE  the baseline being build
  • CC_VIEWTAG the view tag
  • CC_VIEWPATH the path of the view(the same as %WORKSPACE%\view)


  • The plugin supports concurrent builds.
  • Currently you can only have one build at the time per node. Set # of executors to 1 in your node configuration if you want to use concurrent builds with ClearCase UCM Plugin.
  • Only one deliver activity per stream, which means child and sibling modes cannot be executed concurrently.

Run Jenkins service under a valid ClearCase account

Jenkins needs to be authenticated by ClearCase, so it's important that you run the Jenkins service under an account that has the sufficient access to ClearCase. The ClearCase UCM Plugin fully supports that a slave can be in a different ClearCase region or even at a completely different ClearCase MultiSite than the master.If you utilize this feature, it's required that the slave is running Jenkins under an account which has the sufficient credential on the remote site

ClearCase unavailable

The plugin will state in the console output, when ClearCase is not available. This concerns both when it is not installed and when there are no licenses available. If a build has been scheduled, its description is set with the cause.

If you don't get any scheduled builds, check your poll log. This is where to find information, if ClearCase is unavailable.

MultiSite - tag your nodes

If you have slaves in different MultiSites than the master, you can tie the jobs that monitors stream that has mastership on foreign sites to slaves that belongs to those sites. A simple strategy for this is that you add a tag to all you slaves telling which MultiSite they belong to and then you tie the jobs to those labeled slaves.

MultiSite - polling for posted deliveries

The plugin supports polling for posted deliveries in a MultiSite environment. This feature must be turned on at the Jenkins global settings for the plugin, and only has effect in child polling mode. Normally in this mode, the plugin will harvest all baselines made in child streams. If the stream is at a different site, this is not possible. In this setup, the plugin can work in two different modes:

  • Standalone mode: The process is a bit different from normal: on top of making the baseline, the developer must issue a Deliver Baseline command. A special "Posted deliver" object is then created, and the mastership of the development stream is transferred to the integration stream site. The plugin will detect the posted delivery, and resume and complete (or cancel) the delivery. As a result of this, the mastership of the stream will be transferred back to the origin. Notice: The ClearCase posted delivery process does not transfer the mastership of the baseline - for that reason the promotion level of the baseline cannot be changed, but is left as INITIAL. Tags can also not be updated.
  • ClearCase trigger mode: We have developed a ClearCase trigger to set and reset the mastership of the baselines - if this trigger is installed on both the development and integration site, the plugin will behave exactly the same way as in a single site setup: the developer just creates baselines, and everything else will happen automatically. The trigger can be found here: http://wiki.praqma.net/acc/comp/triggers/acc_deliver_baseline. For more information, or help to set this up, please contact Praqma.

Special debugging parameters

Setup logging with plugin versions prior to 1.2.0

For debugging purposes a job can be parametrized to output debug log information to a file. The parameters are string parameters.

  • ccucm_logall - Enable logging(the value part is empty)
  • ccucm_loglevel - The severity of the log level
    • DEBUG - Huge amount of output
    • INFO
    • ERROR
    • FATAL - Only the worst 

Note that these names are case sensitive!

The logs can be found in the jobs build folder under each specific build folder where the debug has been enabled. This means you have to browse into the master Jenkins server.

The SCM log is named ccucmSCM.log and the post-build log is named ccucmNOTIFIER.log.

Setup logging with plugin versions after 1.2.0

From version 1.2.0 the Logging Plugin is required.

So install the Logging Plugin and restart Jenkins, then go to the Job Configuration for the job, and enable logging, use "net.praqma" as logger name:

and then you will find links to the logs from the jobs front page:

Jenkins Job DSL

Available options
job {
    scm {
        clearCaseUCM (String stream) {
            loadModules (String loadModules)                    // loadModules can be: 'ALL', 'MODIFIABLE'. Defaults to 'ALL'
            nameTemplate (String nameTemplate)                  // Defaults to '[project]_[date]_[time]'
            recommendBaseline (boolean recommend = true)        // Defaults to false
            makeTag (boolean makeTag = true)                    // Defaults to false
            setDescription (boolean setDescription = true)      // Defaults to true

            treatUnstableAsSuccessful (boolean success = true)  // Defaults to true
            forceDeliver (boolean forceDeliver = true)          // Defaults to false
            removeViewPrivateFiles (boolean remove = true)      // Defaults to true
            trimmedChangeset (boolean trim = true)              // Defaults to false
            ignoreUnmodifiableChanges (boolean ignore = true)   // Defaults to false
            buildProject (String project)

            pollingMode(String mode, String component) {                        //mode can be: 'CHILD','REBASE','SELF','SIBLING','SUBSCRIBE'. Defaults to 'CHILD'.
            pollingMode(String mode, String component, String promotionLevel){  //promotionLevel can be: 'ANY','INITIAL','BUILT','TESTED','RELEASED','REJECTED'. Defaults to lowest available.
                    //Applicable: All
                    promotionLevel (String promotionLevel)                      //promotionLevel can be: 'ANY','INITIAL','BUILT','TESTED','RELEASED','REJECTED'.

                    //Applicable: CHILD, REBASE, SIBLING
                    createBaseline (boolean create = true)      // Defaults to true

                    //Applicable: REBASE
                    excludeList (String excludeList)

                    //Applicable: SIBLING
                    hyperlinkPolling (String polling = true)    // Defaults to false

                    //Applicable: SUBSCRIBE, SELF, CHILD, SIBLING
                    useNewest (boolean useNewest = true)        // Defaults to false

                    //Applicable: SUBSCRIBE
                    cascadePromotion (boolean cascade = true)   // Defaults to true
                    components {
                        component (String selection)
                    jobs {
                        job (String name, String ignores = null)
job('foo_GEN') {
    scm {
        clearCaseUCM ('bar_dev@\\myVob') {
            pollingMode('CHILD', 'bar_dev_baz@\\myVob', 'TESTED'){

Known Issues

If it's broken ...We Can Fix It!

type key summary

Data cannot be retrieved due to an unexpected error.

View these issues in Jira

Release Notes

1.7.0(August 25, 2016)

  • Major performance improvement: Do not synchronize all command line calls

1.6.9(Febuary 15, 2016)

  • Fixed an issue with poll-sibling not checking mastership of source and target (JENKINS-32490)

1.6.8(December 9, 2015)

  • Fixed an issue with poll rebase and false negatives (JENKINS-31974)

1.6.7(November 5, 2015)

  • Smarter implementaion of (JENKINS-30795)
  • Upped core dependency to 1.580.

1.6.6(October 16, 2015)

  • Allow manual rebuild of failed integrations (JENKINS-30795)
  • Fixed an issue where polling could start prematurely (JENKINS-30507)

1.6.5(September 16, 2015)

1.6.4(September 3, 2015)

1.6.3(July 6, 2015)

1.6.2 (June 16, 2015)

  • Fixed an issue for poll rebase with baseline creation (JENKINS-28835)

1.6.1 (April 14, 2015)

1.6.0 (Febuary 17, 2015)

  • Implemeneted a new poll sibling mode using hyperlinks (JENKINS-26484)
  • Fixed a performance issue when dealing with large changesets. (JENKINS-26593)

1.5.5 (November 20, 2014)

  • Fixed an issue with loadrules not used properly (JENKINS-25647)
  • Project templates are now calculated on the executing node (JENKINS-25342)

1.5.4 (November 4, 2014)

  • Fixed an issue with poll sibling and calculation of changeset (JENKINS-25059)
  • Implemented the option to filter changes under read-only components. (JENKINS-23533)

1.5.3 (August 15, 2014)

  • Performance improvement, use catcs for loadrules (JENKINS-23245)
  • Performance improvement, load rules for swipe (JENKINS-23246)
  • Implemented tests to run on slaves (JENKINS-19658)
  • Fixed an issue where output is accidently sent to wrong log (JENKINS-18107)
  • Warn me when version becomes too long, run relatively to view. (JENKINS-23268)
  • Escape the object selector if '&' is present (JENKINS-23920)


  • Changed maintainer

1.5.1 (January 23, 2014)

1.5.0 (November 19, 2013)

This release includes a major bump in Jenkins core requirements. This was done in order to implement the change listed below. Users of a Jenkins version older than 1.534 should use version 1.4.4

  • Changeset is now not lost, when a deliver fails. (JENKINS-19558)

1.4.4(November 17, 2013)

1.4.3(September 19, 2013)

  • Fixed a serialization regression issue introduced in 1.4.2

1.4.2(September 18, 2013)

  • Incorrect promotion level displayed at ClearCase failure (JENKINS-19410)
  • Remove reminiscent of old logging method (JENKINS-19404)
  • Possibility to remove the contributing activities from the change set of the build (JENKINS-18281)
  • Provide an option to not delete view-private files at the start of each build (JENKINS-18280)
  • Keep the snapshot update files in the workarea (JENKINS-18279)
  • Change set is not correctly calculated after a rebase of the integration stream (JENKINS-18278)

1.4.1(September 16, 2013) Faulty release

1.3.8(June 4, 2013)

1.3.7(May 17, 2013)

1.3.6(April 2, 2013)

  • If Jenkins job fails cancel deliver Jenkins can never get out of this situation (JENKINS-17445)
  • Finding the correct delivering Stream to cancel (JENKINS-17067)

1.3.5(February 15, 2013)

1.3.4(February 6, 2013)

1.3.3(January 31, 2013)

  • Fixed an issue when using the FilePattern for baseline template (JENKINS-16541)

Note: (Only)This release mistakenly will never process baselines again even though the promotion level is flipped manually.

1.3.2(January 23, 2013)

  • Fixed display issue for jobs using ANY as promotion level, was displayed as null in console (JENKINS-16447)
  • Fixed 'Enabling poll for posted deliveries' breaks polling for poll self (JENKINS-16422)
  • Fixed 'Allow for non composites in posted deliver' (JENKINS-16371)
  • Implemented table format for changesets (JENKINS-16271)
  • Fixed 'Missing baseline' for manually triggered jobs using PollSelf (JENKINS-16072)

1.3.1(December 12, 2012)

  • Fixed missing baseline issue with latest plugin (#16072)

1.3.0(December 3, 2012) - Deprecated.

  • Resolved issue with polling (#16763)
  • The build-data layout changed in 1.3.X, so we cannot guarantee backwards compatibility with existing jobs, where there are old jobs built in 1.2.0.

1.2.0(September 21, 2012)

1.1.7(September 10, 2012)

  • Stream is not loaded (#15089)
  • Add headline to changes (#15092)

1.1.6(August 17, 2012)

  • Multisite polling finds the same baseline (#14806)

1.1.5(August 7, 2012)

  • Use the current streams project, if the jenkins build project is not found (#14702)

1.1.4(July 16, 2012)

  • Don't display all versions in the changeset (#14436)
  • If deliver fails an undo deliver must always be executed (#14318)
  • Deliver being cancelled not detected (#14317)
  • CCUCM mistreats deliver error (#14241)
  • Changlelog is missing user names (#14240)
  • Sometimes CCUCM finds baselines in other masterships (#14239)
  • Missing hyperlink type "tag" in Clearcase does not fail the build (#13944)

1.1.3(July 13, 2012)

  • Faulty release, please wait for version 1.1.4 on July 16.

1.1.2(June 19, 2012)

  • Fail gracefully when no ClearCase licenses (#14147)

1.1.1(June 6, 2012)

  • Build variable CC_BASELINE not populated with used baseline (#13970)

1.1.0(May 31, 2012)

  • Enhance the posted deliveries polling, so it can work 'as normal' (#13964)
  • Logger error crashes server (#13983)
  • Console output shows the wrong version number (#13984)
  • ClearCase UCM post build step issue (#13985)
  • Baseline template stalls jenkins (#13986)

1.0.7(Mar 19, 2012)

  • Added support for polling for posted deliveries (#13574)
  • Streams with different mastership are ignored - unless Polling for Posted Deliveries is turned on (#13575)

1.0.6(Mar 14, 2012)

  •  Baselines are created with -identical switch: Don't do that (issue #13067)

1.0.5(Feb 10, 2012)

  •  This version was just a release #€&%#? - nothing change between 1.04 and 1.0.5 ...except the version number in the POM ;-)

1.0.4(Feb 10, 2012)

  •  Null pointer execption in buildEnvVars (issue #12708)
  •  Fixing empty logs on non-remote slaves (issue #12709)
  •  A build must fail, if the baseline name template is erroneous (issue #12705)
  •  Correct the message if there is not an available hltype:tag (issue #12706)
  •  Add env and file as baseline template parameters (issue #12707)

1.0.3(Jan 9, 2012)

1.0.2(Dec 16, 2011)

  • Adding filename template
  • Polling.log should be split into several log files (issue #12710)

1.0.1(Nov 17, 2011)

  •  baseline template support env vars
  •  Problems with recommending baselines (issue #12712)

1.0.0(Oct 25, 2011)


  1. Unknown User (rmyung)

    Is there a logger that we can look at?

    The plugin does not output much information on what is happening, such as the name of the view created, streams created, etc.

    I'd like to know if cleanup is required.

    1. Unknown User (rmyung)

      Also, where is the storage location for the snapshot view?

    2. Unknown User (wolfgang)

      Hi there.

      Please refer to the updated wiki!

      Regarding information on what is happening, the plugin should state information about the view, for example:

      [CCUCM] View root: C:\Documents and Settings\student\.jenkins\jobs\proj1\workspace\view
      [CCUCM] View tag : CCUCM_proj1_CCCQ7

  2. Unknown User (rmyung)

    Thanks.. this plugin is ALMOST what I want.  It handles UCM so much better than the main Clearcase plugin, but I wish it had support for dynamic views.

    I'm unable to find this plugin as a component in Jira, but please look into adding that feature.

    1. Unknown User (jstruck)

      Could you please try to explain, why you wish to use dynamic views since there normally is a major IO interaction connected to building code, where a snapshot would performe better, because its on the local disk where as the dynamic view would cause huge load in youre network. 

      please email me whit your description well be happy to look into this and develop this as a feature if there is a good reason for it

  3. Unknown User (lars_kruse)

    Do we Need To support Dynamic Views?

    Some of the feed-back we have had regarding the ClearCase UCM Plugin has been aimed towards the fact, that we don't use or support dynamic views. This comment is meant to give you an insight into our rationale for this design decision.

    In Praqma we have been working with ClearCase and various other SCM/VCS systems for what seems like ...forever (well 13++ years for my part). Jenkins and Hudson has been part of our expertise within the last 2 years. We are striving to put our ClearCase knowledge into the plugin; Instead of doing less - and leaving the complicated parts left over to be managed manually, we are aiming to make our plugin as simple, elegant, efficient as the ones used in Git, Mercurial, Bazaar and SVN by doing it all!

    A ClearCase view is an odd construction which basically just is a necessary ClearCase artifact that's required to make things work because of the internal architecture in ClearCase - none of the other SCM systems has this rule-based extra layer on top of the repository - they just plain 'checkout', 'get' or 'branch' - it's simple and it works.

    Since the introduction of ClearCase UCM, the need for writing config specs and managing views has been almost as easy as in the other tools: You define you configuration and creates the view. That's it. And even if the config spec has to change now and then - as your integration stream advances, you still never touch the config spec directly. You simply rebase your stream and the config spec is updated accordingly - it's done automatically. Only thing you have to do is update your views.

    We want to take advantage of the features that UCM offers. The fact that view management can now (relatively easily) be done automatically is a winner: You just say stream and component - and we find the relevant baseline and create the view for you. We WANT it to be easy and simple.

    We use snapshot views because the have a tendency to have a much better over-all performance when it comet to processing (building) large file structures. If the file structures aren't large, then loading and building takes only a short time. And a short time (in a snapshot views) compared to a slightly shorter time (in a dynamic view) doesn't mean that much of a difference ;-)

    Dynamic views are located on the MVFS (Multi Version File System) drive - usually the M:\ drive) but we wanted the jobs work space to be "self-contained" as in the git, SVN, Mercurial and Bazaar plugins. We wanted the view to be a structure inside the job's workspace.

    Besides snapshot views are the only views that are available to ClearCase LT, so going for dynamic views would make the plugin incompatible with ClearCase LT. And finally; developers tend to har a preference towards snapshot views (because of the overall better build performance) so If we want to make the build on Jenkins as close to the scenario that the developers uses for development (and we do!) then snapshot views are the ones to go for.

    We have optimized the use of snapshot views (I dare say to perfection!) snapshot views are reused within the same workspace, thus updating it doesn't mean loading everything again - only the deltas since the previous baseline that was build in the workspace - if you do continuous integration (and I assume Jenkins users are ;-) then that's usually not much!

    Our use of snapshot views is very robust:
    - You can swipe the workspace (including the view.dat file in the view root!) ...and the view tree will just be recreated in the next build
    - You can delete the view - and it will just be recreated by the next build
    - You can even make the view stranded (remove the view tag but keep the view storage) -  and we will just tag it up again automatically if we need it.

    We have thought a lot about this, we believe that we are doing the right thing.

    Do we need to support Dynamic Views as well?  Hmmm maybe, but let's put it to the test:

    Try to set up your builds using our plugin as we designed it - using snapshot views and evaluate it without prejudice.
    If you still miss the dynamic views, try to explain to us what exactly you are missing, that the snaphot views can not provide - and we promise that we will listen very carefully.

    Best Regards

    Lars Kruse

  4. Unknown User (nicolas_romana)


    It is written that this plugin only supports Clearcase windows clients. What are the problems with linux Clearcase ?

    How difficult is to improve the plugin in order to support linux clients ?

    1. Unknown User (wolfgang)


      We've made some mistakes to make the plugin general in terms of paths and fully qualified version names.

      Much of the code will work, but it is not tested at all on linux.

      I'm not sure how much time it will take to make it support linux.

  5. Unknown User (coend)

    After using this plugin for some time I now have a problem with a new project/workspace:

    [CCUCM] View root: C:\localdata\Jenkins\workspace\PROJECT_copy\view
    [CCUCM] View tag : CCUCM_PROJECT_copy_PC
    [CCUCM] Determine if view tag exists
    [CCUCM] Creating new view
    Selected Server Storage Location "3th_choice_ViewStorageLocation".
    cleartool: Error: Unable to create directory "\\pc283\view_storage_location\DOMAIN\djoe\view": No such file or directory.
    [CCUCM] SCM exception: View not found in this region, but views with viewtag 'CCUCM_PROJECT_copy_PC' might exist in the other regions. Try changing the region Hudson or the slave runs in.
    [CCUCM] Could not establish workspace: net.praqma.hudson.remoting.EstablishResult@1fdaa47
    [CCUCM] Pre build steps done
    Unable to end the view CCUCM_PROJECT_copy_PC: Could not end view CCUCM_PROJECT_copy_PC: cleartool: Error: View tag not found: "CCUCM_PROJECT_copy_PC".
    Finished: FAILURE

    I'm not sure what goes wrong but assume it has to do with the following:
    - The clearcase environment has multiple storage locations; there is no default but a best choice is done depending on the number of views, etc.
    - The generic view name 'view.vws' might clash with other views.

    Would it be possible to add a field in the plugin, in which a storage location can be specified?

    Would it be possible to name the view <view-tag>.vws instead of view.vws?

    1. Unknown User (lars_kruse)

      Hi Coen

      Thanks for your feed back.

      To reply to your feature request first:  "Would it be possible to add a field in the plugin, in which a storage location can be specified?".

      Certainly! This is only a minor change and we can add this feature in our next release.

      Currently we create the view without specifying any storage location (which is the same as using -stgloc -auto) This will fail if you don't have any storage locations defined, but in the case where you have several clear tool will pick one for you according to the following algorithm:

      1. Server storage locations with global paths (--gpath) that reside on heterogeneous hosts are disqualified.
      2. Local server storage locations are preferred over remote ones.
      3. A server storage location is selected at random from the remaining candidates. 

      So this ought not to be the problem, and from you log I can see that the CCUCM plugin actually managed to pick a storage location: 


      But it looks like the user (djoe) doesn't have the sufficient access to create the view on this location

      You ask if the fact that the view storage is named view.vws doesn't clash with other views and if we could name if after the view tag instead of the leaf folder in the local view tree.

      The short answer is; "It doesn't clash": cleartool has the unfortunate habit of creating a storage the matches the leaf folder and not the tag - we agree with you, that this is not pretty! If this shall be fixed we must direct the location of the view storage with the -vws switch to the mkview command - we will consider this - cleartool's own built-in solution sure is ugly!

      The solution cleartool implies automatically is - as always in cleartool when there is a chance of a name clash - to throw in an integer. So if you run a cleartool lsview command you see all you Jenkins related views located in view.xx.vws folders.

      We will consider fixing this too, although it only a cosmetic change.

      But in your case where you have one of the potentially automatically selected storages that you can't write to, you will need some way to control which storage is used, and we will provide you with that option.

      Until that is released you can do the following:

      1. Create a new (cleartool mkregion Jenkins) region called Jenkins
      2. Copy all your VOB tags to the region (something like: foreach `lsvob ...` do `cleartool mktag -region Jenkins -vob -tag ...`)
      3. Set up (cleartool mkstgloc -view ...) just ONE view storage pointing to where you want to be
      4. Change the region of the Jenkins slaves and masters to Jenkins.

      Or you can simply remove the stglocs that aren't valid - to make sure that the automatic choose done but cleartool doesn't break the build.

      I created a case on this subject: https://issues.jenkins-ci.org/browse/JENKINS-13234

      1. Unknown User (coend)

        Thanks for the explanation.

        I'm no clearcase administrator, so I can not do this clearcase things myself, but I'll ask an administrator.

        For the time being: I'll just recreate a job if one fails. I don't create a new job that often...

      2. Unknown User (gcook)

        "Would it be possible to add a field in the plugin, in which a storage location can be specified?".

        I take it this would be very similar to how the "UCM ClearCase" plugin works whereby you have  the option "View storage" where you can either "Use Server storage location" or "Use explicit path". It seems that your plugin "Clearcase UCM" is going down the route of using the server storage location and there is no way of doing an explicit path. This would be a great feature to have. 

        Your comment was from March 2012 so has this progressed any further?

  6. Unknown User (jagankalluri)

    Hello,   We are trying to set up Jenkins and i tried using this plug in since we use Clearcase UCM ended up with below error shown in snapshot below. can some one please look in to this andl et m eknow where we are wrong on this.

    Build out put says can not find stream .

    Job Configuration Set up

    Cleartool located at :

    1. Unknown User (rmyung)

      Jagan, are you able to manually do an lsbl command on that stream?

      cleartool lsbl -stream stream:icm_psl_etcetc  ?

  7. Unknown User (mred589)

    This plugin looks fantastic, but I can't get it to work for the life of me.  My setup looks like this.
    I get the following output.
    Now this confuses me, because I know that there are baselines in that view, but I'm not sure what the line "[CCUCM] Scanning 0 streams for baselines." Means. I've tried tweaking pretty much every setting, all to no avail.

    I've also tried to enable the logging feature shown in the documentation above by adding both the parameters ccucm_logall and ccucm_loglevel to the config, but I don't get any debug files in the build directory (%JenkinsHome%\builds\<BuildName>) I'm sure I'm missing something really trivial. If anyone can help, it would be greatly appreciated

    1. Unknown User (lars_kruse)

      Hi Ed

      From your description of what you expected to see, I thing that you simply need to use the plugin in self polling mode - instead of sibling polling mode.

      In self polling mode, the plugin looks for baselines on the string you've specified in the setup. This is the read-only mode of the plugin

      In child ond sibling polling mode the plugin will try try to integrate for you - this is write mode - or pret-tested deliveries mode

      In child mode it looks for baselines on child streams 

      In sibling mode it looks for baslines on streams that has the specifide streams as default target (inter-project deliveries)

      ...Let me know if it helps you!

    2. Unknown User (jbrejner)

      Hi Ed.

      Which user runs that job - be aware that the user running the job - the jenkins service - must have rights with respect to Clearcase, that means that the job as a minimum should run as you or a similar userprofile. In general we recommend the jenkins service user should be member of ClearCase administrators group, but that is only to make life easier.

      What happens if create a different job, without the plugin and just calls the shell with: "cleartool lsvob" ? We expect a listing of the vobs in the buildmachine's region.

    3. Unknown User (wolfgang)

      Hi Ed!

      Sorry for not updating the wiki, but from version 1.2.0 the plugin requires the Logging Plugin for logging.

  8. Unknown User (mred589)

    I think I have my first problem solved.  My problem was that I was attaching the plugin to a non-integration stream, and it wasn't really liking that.  Switching it to point to the related integration stream, and changing the mode to self solved my problems..... and brought me to my next set of problems.

    1. I see that at some time, the "newest" feature was deprecated (this took a lot of sleuthing, as the wiki page still documents it, but it doesn't show up as an option).  My current stream has approximately 300 different baselines and I don't want to wait weeks while jenkins tries to rebase and build each one in turn.  Is there a way to either re-enable the newest capability OR come up with a way to manually advance the "current" baseline to the most recent one?  I don't really have a problem if the build server builds every baseline, I just want it to start with the current reasonable one.

    2.  In our current model for development, we have about 6 different projects.  They all reference each other, and a number of them have scripts where compiled files are copied between projects to make sure they have current references.  Right now our build server has perl scripts that rebase the stream to the latest baseline, compiles all the projects, then checks in the compiled binaries so that our developers aren't required to build every single project every time they rebase, only the projects they've modified.  The problem that I'm having now is that this plugin seems to have mounted the steam as read-only, which doesn't allow this possibility.  Lars mentioned something about self polling mode being read-only.  I'm still trying to understand how this works, as when I switch the plugin to child polling mode, it doesn't find any baselines, but does find all the child streams.

    I'm going to keep digging this.  Thank you very much for the help sofar.  It's good to know there are people out there that understand this better than I do.

    1. Unknown User (lars_kruse)

      Hi Ed

      Happy that you got the first issue sorted out. Regarding "newest"; sorry for the bad documentation - we'll review it! What your are supposed to do in order to get the plugin to skip the uninteresting baselines is simply that you should make them ...uninteresting! Set the promotion level to REJECTED and the plugin wont find them.

      OK so why is the stream read-only in self mode? It's described in the blog "The rationale behind the plugin" referenced in the top of this page - it's du to performance. ....An to the fact that you shouldn't do automated rebase - instead you should do pre-tested deliveries. In these two scenarios (poll sibling and poll child) you are right: You'll ret writeable streams as you target, but your action is push (deliver) not pull (rebase). 

      To me it sounds like the approach "....a number of them have scripts where compiled files are copied between projects to make sure they have current references" could be handled through configuration. Rootless components and composite baselines in ClearCase UCM are actually there to solve this issues. An alternative approach is to introduce an artifact management system to assure build-avoidance and maintain the dependencies. Having scripts that tosses files around will always be a challenge to a CI process - try to avoid that.

      If you want to discuss the issue (a possible solution using composite baselines) I'd be happy to help - catch me on Skype: lakruzz.


      1. Unknown User (mred589)

        That makes sense.  I apologize for not reading the "rationale behind the plugin" page.  Based on the title and the heading it didn't seem terribly relevant, but it goes into far more depth than just rationale.  My original goal was to bring this up in parallel with the build system we currently have; It seems like the usage model doesn't really allow that, as baselines are how tracking is done. (Not a negative comment, as the usage model makes a lot more sense this way).

        Based on what I'm seeing, I'm not sure why the "newest" flag was deprecated.  Reading through the rationale document shows this model.

        1st jenkins job.  Build and integrate 

        2nd jenkins job.  Build and short unit test, Promote baseline to "BUILT"

        3rd jenkins job.  Test in depth.  Promote baseline to "TESTED"

        This is where I find the problem with the "newest" flag being deprecated.  My functional tests take on the order of 6 days (144 hours) to complete and need to run on 5-10 different platforms simultaneously.  This means that I can realistically have one full functional test run per week.  If Jenkins is testing every built baseline, my SQA cycle falls behind after the second baseline in a week.  Today, our functional test scripts are set up to poll the build server for the newest baseline, and start their testing from there.  Without a newest flag, I'm not sure how I could support this on Jenkins.

        I'm sure I'm missing something....  I'll keep digging.

        1. Unknown User (wolfgang)

          There is also the ANY promotion level, which will let you do as the Git and Subversion plugins do. This special promotion level will let you bypass the promotion level check and always build the latest baseline regardless of promotion level.

          Check the "Latest baseline" section in the documentation.

          1. Unknown User (mred589)

            The ANY promotion level is problematic because it doesn't actually advance the baseline status.  In the 3rd Jenkins job I'm trying to advance the baseline to TESTED, but I can't do that if I have the ANY promotion level set.  I'm sure there's a way to accomplish what I'm trying to do, I'm just not sure how to get there.

            1. Unknown User (wolfgang)

              1. Unknown User (mred589)

                I completely agree that the ANY promotion level has some odd use cases, and doesn't quite match what I'm trying to do.  What I think would match would be to have a INITIAL promotion level along with a "newest" control, but that seems to have been deprecated for some reason.

  9. Unknown User (rahulvikky)

    As per Lars(Go to the below link location), the plugin does support Linux clients unlike the Limitation section content of this page.


    Can someone please clarify and correct either of the docs?

    1. Unknown User (lars_kruse)

      Sorry, I've updated the wiki page descriptions. This plugin does indeed run on both AIX, Ubuntu and Red Hat ...these er just the *nix variants that I positively know about. I expect it to be compliant with any ClearCase client out there!

  10. Unknown User (anand_jenkins)


    anybody did Clearcase UCM Plugin build with baseline configuration.


  11. Unknown User (anand_jenkins)


    Can someone please clarify me why i am getting this error ? . I am running Jenkins from one of my VDI machine  and connected to clearcase windows server. i am able to get the latest baselines so basically it is getting connected to clearcase server, but i am not sure why it is changing the stream name while running the command.

    Building in workspace C:\Jenkins\workspace\Test Forms
    [CCUCM] ClearCase UCM Plugin version 1.7.0
    [CCUCM] Allow for slave polling: false
    [CCUCM] Poll for posted deliveries: false
    [CCUCM] Trim changeset: false
    [CCUCM] Polling streams: self
    [CCUCM] Getting baselines for :
    [CCUCM] * Stream: XXXXX_XXX_POC_Int@\pvob
    [CCUCM] * Component: XXXX@\pvob
    [CCUCM] * Promotion level: ANY

    [CCUCM] Retrieved 4 baselines:
    [CCUCM] + XXXXX_v2014.12.011(Tue Jul 18 11:45:32 PDT 2017)
    [CCUCM] + XXXXX_v2014.12.012(Thu Jul 20 09:56:15 PDT 2017)
    [CCUCM] + XXXXX_v2014.12.013(Thu Jul 20 10:39:13 PDT 2017)
    [CCUCM] + XXXXX_v2014.12.014(Thu Jul 20 14:23:05 PDT 2017)

    [CCUCM] Using XXXXX_v2014.12.014@\XXXXXX
    [CCUCM] View root: C:\Jenkins\workspace\Test Forms\view
    [CCUCM] View tag : CCUCM_Test_Forms_XXXX27005736
    [CCUCM] Determine if view tag exists
    [CCUCM] Creating new view
    Unable to create view CCUCM_Test_Forms_XXXX27005736 at C:\Jenkins\workspace\Test Forms\view
    Command was: cleartool mkview -snapshot -stgloc -auto -tag CCUCM_Test_Forms_XXXX27005736 -stream stream:CCUCM_Test_Forms_XXXX27005736@\pvob "C:\Jenkins\workspace\Test Forms\view"
    cleartool: Error: No available Server Storage Location entries.
    Command: cleartool mkview -snapshot -stgloc -auto -tag CCUCM_Test_Forms_XXXX27005736 -stream stream:CCUCM_Test_Forms_XXXX27005736@\pvob "C:\Jenkins\workspace\Test Forms\view"
    Path: null
    at net.praqma.hudson.remoting.CheckoutTask.invoke(CheckoutTask.java:125)
    at net.praqma.hudson.remoting.CheckoutTask.invoke(CheckoutTask.java:33)