We're seeing this too... did you ever figure it out?

Unfortunately, no.

I have the same problem, and as far as I have noticed,
the plugin doesn't work for any "derived object version".

The Plugin detects changes on an element like this:
% cleartool desc element
version "element@@/main/1"

But it doesn't detect changes on an element like this:
% cleartool desc element
derived object version "element@@/main/1"

Could you please show your clearcase scm configuration?

I'm also having trouble with clearcase/windows:

My Base ClearCase polling log always says no changes.

cleartool lshistory -all -since 11-apr-13.21:21:19utc+0000 -fmt '\"%Nd\" \"%u\" \"%En\" \"%Vn\" \"%e\" \"%o\" \n%c\n' -branch brtype:main -nco Z:\MY_STUFF

Done. Took 1.9 sec
No changes

But when I run that "cleartool lshistory" without the insane "fmt" in a CMD window I do see changes:

Z:\MY_STUFF>cleartool lshistory -since 11-apr-13.21:21:19utc+0000 -branch brtype:main -nco .
--04-11T17:25 moncreg create version "FOO@@\main\85"
"COMMENT"
--04-11T17:25 moncreg create version "BAR@@\main\49"
"COMMENT"

When I run that command with the insane "fmt" in a CMD window, it chokes on the FMT

When I run that command with the insane "fmt" in a cygwin/sh window, it looks like it works.

I started Jenkins in a CMD window, to give it 6 GB of JVM memory, as cygwin wouldn't let me give more that 3 GB.

I'm using

Jenkins ver. 1.480.2

Jenkins ClearCase Plug-in

This plugin makes it possible to retrieve files from a ClearCase SCM using a configspec. 1.3.14

Any advice?

Same issue (Jenkins 1.510 and ClearCase 1.3.14).
Maybe you can confirm, but it seems to be related to using different platforms for master and slave:
Master: Unix/Solaris
Slave: Windows
or
Master: Windows
Slave: Unix/Linux

ClearCase polling log looks good but "No changes" is reported.
I have the impression that is related to the mix of slashes and backslashes for the polling output
(e.g. on Windows using backslashes) and comparing them with the polling rules (e.g. on Unix master).
It does not help if I define the polling rules with backslashes in order to match the Windows slave polling output.
In order to confirm this theory I moved a polling job from Windows to Unix and - now it works!
The Unix SCM polling job triggers then the Windows build job.
So I would say (and also found other, older quotes confirming that): SCM polling needs to run on master
Of course I voted here to get this fixed and fianlly working transparently.

Actually for this defect this is a workaround that at least works.
Of course I'm aware of hierarchical VOB tags (which we also use).
In our case we do polling and (Unix) view cleanup on Unix and call the
compile job on the Windows slave, which uses the same view.
Although they have different tags, the compile spec from Unix works on the Windows client.
(ClearCase works with oids, so the Unix view works with Unix compiled rules also on Windows!)
As our PCs are diskless and have no local storage, they use Unix views anyway.

However, if there is one I'd appreciate any other workaround that helps.
This comment was also intended as hint to analyze the issue which seems
to be specifically related to the master/slave platform change.

I'm not using hierarchical view tags but we are doing builds with Jenkins using ClearCase on both Windows and Linux. My master is Windows (due to environment constraints) and we have both Windows and Linux slaves. I see this issue for projects built on the Linux slaves.

The issue is the same as described above - it lists changes in the polling log. However, it doesn't pick them up and at the end says No Changes. It is reproducible on two mainline builds of the same codebase. The only thing that differs in the ClearCase portion is the view tag.

Master machine is Windows Server 2008.

I was poking around a bit further. It looks like using the same version of the plugin, but changing Jenkins versions reproduces the problem. If I run on 1.424, the plugin correctly gets the path separators by checking RemoteLaucher.isUnix() (which returns true). However, now on Jenkins 1.518, it is producing a Windows separator matching expression by using isUnix on the hudson.Launcher that gets passed in, which is returning false.

Haven't had a chance to dig deeper, but will try later tonight or tomorrow.

Poking more - I think this may be specific to when the RemoteLauncher is decorated by an environment. The anonymous inner class for this case in Launcher.java doesn't override isUnix. So what happens is that the path check ends up being run instead (from the basic Launcher), and the isUnix variable that is normally taken from the SlaveComputer gets ignored.

Seems like a simple change, but not sure what else it may break. I will give it a try.

For me, the problem is fixed with a build of 1.520 (see linked JIRA) - perhaps someone else can confirm as well?

Sounds good!
v1.520 is not yet offered for me for update (1.519 is latest).
I'll test it and post a note as soon as it's available.

I just updated to 1.520 and now it works fine.

Updated yesterday to 1.520.
Seems to detect changes properly now over misc. platforms (Linux Slave - Windows Master),
which did not work before.

I'm closing as fixed even if the bug was not in the plugin but rather in Jenkins core. Issue is fixed in Jenkins 1.520+