The first request is one I've looked into in the past and may make another run
at in the future, but it's a fairly low priority for me. While many shops may be
using their own homebrewed scripts for view creation etc, that poses as many
difficulties to implement as it provides benefits - you'd to do it right, it'd
have to be very, very generic with lots of configuration required by the user. I
can't help but think the ClearCase plugin has already gotten unwieldy and
excessively complicated to configure, so I'm wary of adding more complexity.

Regarding the next two - again, that's more configuration for specific use cases
than I really feel is a good thing. You can already get a good chunk of what
you're looking for in the second option by specifying paths in multiple VOBs in
the load rules - the end result is the same as if you defined CLEARCASE_AVOBS
and ran lshistory -avobs. And I'm not really clear on what the reason is for
wanting view names in load rules in the first place?

for issue 1: I agree simpliciy rules

• I already don't use the scm plugin to generate the config spec,
• you currently have a question on additional mkview commands. By making that a
  radio button and 2 diffent options underneath, it would keep it simple?
  question1: do you have addional mkview options
  question2: what script to run, options for the script would be taken from the
  parameterized build plugin. e.g. I specify a baseline label in the parameters
  and use that as input to the clearcase plugin

for issue2 : for the viewname I currently take a parameter from parameterized
build, which is the label and make that the viewname (userid_LABEL). That
becomes input to the clearcase viewname field. The load rules have a list of
view centric paths, that need the above create view.

In addition, i create multiple jobs for the same project. e.g. coverity run,
code coverage run, .... And we create different jobs for release vs.
integration activities. By keeping the load rules generic, i can just copy the
job and make less mistakes.

I think you may be best off forking the plugin and implementing the
functionality you want there - I don't think I'll be adding any of this to the
main ClearCase plugin in the near future.

I'm still confused about the second/third request - this, obviously, relates to
issue 4222. Why do you need "/view/my_viewname/vobs/xpuModule" instead of
"/vobs/xpuModule"?

I can test it in version 1.02 later, but specifying
just /vobs/oam , /vobs/fcl , ... in "vobs path" in plugin version 0.91 gives me
this result:

[ngrbs_iser2.1] $ /usr/atria/bin/cleartool lshistory r -since 11-sep
09.19:35:57utc+0000 -fmt '\"%Nd\" \"%u\" \"%En\" \"%Vn\" \"%e\" \"%o\" \n%c\n' -
branch brtype:i_iser -nco /vobs/oam /vobs/fcl /vobs/dataplane /vobs/ipsec
cleartool: Error: Unable to access "/vobs/oam": ClearCase object not found.
cleartool: Error: Unable to access "/vobs/fcl": ClearCase object not found.
cleartool: Error: Unable to access "/vobs/dataplane": ClearCase object not
found.
cleartool: Error: Unable to access "/vobs/ipsec": ClearCase object not found.
FATAL: Base ClearCase failed. exit code=1
FATAL: cleartool did not return the expected exit code. Command
line="lshistory -r -since 11-sep-09.19:35:57utc+0000 -fmt \"%Nd\" \"%u\" \"%
En\" \"%Vn\" \"%e\" \"%o\" \n%c\n -branch brtype:i_iser -
nco /vobs/oam /vobs/fcl /vobs/dataplane /vobs/ipsec", actual exit code=1
java.io.IOException: cleartool did not return the expected exit code. Command
line="lshistory -r -since 11-sep-09.19:35:57utc+0000 -fmt \"%Nd\" \"%u\" \"%
En\" \"%Vn\" \"%e\" \"%o\" \n%c\n -branch brtype:i_iser -
nco /vobs/oam /vobs/fcl /vobs/dataplane /vobs/ipsec", actual exit code=1
at hudson.plugins.clearcase.HudsonClearToolLauncher.run
(HudsonClearToolLauncher.java:100)
at hudson.plugins.clearcase.ClearToolExec.lshistory
(ClearToolExec.java:90)
at hudson.plugins.clearcase.history.AbstractHistoryAction.runLsHistory
(AbstractHistoryAction.java:81)
at hudson.plugins.clearcase.history.AbstractHistoryAction.getChanges
(AbstractHistoryAction.java:67)
at hudson.plugins.clearcase.AbstractClearCaseScm.checkout
(AbstractClearCaseScm.java:296)
at hudson.model.AbstractProject.checkout(AbstractProject.java:898)
at hudson.model.AbstractBuild$AbstractRunner.checkout
(AbstractBuild.java:400)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:349)
at hudson.model.Run.run(Run.java:1106)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:93)
at hudson.model.Executor.run(Executor.java:122)

The same test with plugin 0.91: now specifying view centric path works:

[ngrbs_iser2.1] $ /usr/atria/bin/cleartool lshistory r -since 11-sep
09.23:18:45utc+0000 -fmt '\"%Nd\" \"%u\" \"%En\" \"%Vn\" \"%e\" \"%o\" \n%c\n' -
branch brtype:i_iser -
nco /view/ngrbs_iser2.1/vobs/oam /view/ngrbs_iser2.1/vobs/fcl
[workspace] $ /bin/sh xe /usr/local/apache-tomcat
6.0.18/temp/hudson8232978384152728254.sh

Yeah, that's behavior that changed from 0.9 to 1.0 - while changing to lshistory
-all, I standardized how all the various view types (base/UCM, snapshot/dynamic)
determined the paths to pass to lshistory, and started requiring "load rules"
for all view types as well. Now you can use "/vobs/some_vob", "vobs/some_vob",
"load /vobs/some_vob", or "load vobs/some_vob" (the latter two to deal with the
fact that using the term "load rules" makes it seem like you may need "load ",
and I decided it was easier to just tear it out if it showed up than to find a
clear enough wording to explain it), and any of them will result in "cleartool
lshistory -all -since (blah) -fmt (blah) vobs/some_vob", run from the view
directory.

And I guess I could look into parsing out the "/view/my_viewname" the same way I
do "load ", but it seems superfluous, since you really can just specify
"/vobs/some_vob" in 1.0 and later. =)

I think just specifying /vobs/oam, ... will work if you execute the lshistory
within a setview command, e.g.

cleartool setview -exec 'cleartool lshistory -all .... ' $CLEARCASE_VIEWNAME

In the log I see it executes a cleartool startview which will only mount the
view to /view. And it makes total sense for snapshot views, but not as much for
dynamic views.

I am confused in what directory it executes that lshistory command. If it is
the workspace that would not work since i don't have any sources there.
If it executes that command in /view/my_viewname then it should work in version
1.0 as you state.

Will test it in another installation I have.

It executes in a different place depending on the view type:

• for snapshot: (workspace)/view_name
• for dynamic: (view drive)/view_name

Basically, no matter what, it's running from the root of the actual view.