-----Original Message-----
From: Jason Smith [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 02, 2005 9:27 AM
To: [EMAIL PROTECTED]
Subject: Ant Clearcase tasks
Hi Rob.
Was wondering if you're still maintaining the ant clear case
tasks? I sent
this email to the addresses on the javadoc for the clearcase
task. They all
bounced except your old address.
Regards,
Jason
---------------------- Forwarded by Jason Smith/ZI/USA/Zurich
on 08/02/2005
11:23 AM ---------------------------
Jason Smith
08/02/2005 11:14 AM
To: [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]
cc:
Subject: Ant Clearcase tasks
Hello gentlemen.
Here at Zurich Insurance, we are fans of your ant tasks for clearcase.
We've been using them in our nightly build tasks for several
years now.
I'd like to share with you an enhancement that we recently
made. We added a
nested fileset element to the checkin, checkout, and
uncheckout tasks. We
had a task for our build where we were going to be doing more
automated
code generation as part of our build and we really couldn't
figure out a
better solution than to update the ant tasks to support filesets. The
cleartool command for these tasks allow multiple files. The syntax is
really simple, instead of just one file at the end of all the
commandline
options, just start listing more files. This code is against the 1.6.5
source.
(See attached file: ClearCase.java)(See attached file:
CCCheckout.java)(See
attached file: CCUnCheckout.java)(See attached file: CCCheckin.java)
There were two design questions I wrestled with and would be
available to
change the implementation if you thought there was a better
way. First,
much of the logic for filesets would be shared across the three tasks.
Should it go in a base class? I said yes. Should that base
class be the
clearcase task even though other classes that don't use that
logic extend
it? I also said yes. I thought it was consistent with the
handling of the
viewpath argument which is basically the same situation.
There could be an
argument to be made that viewpath has wider applicability
than the file set
argument, but it seemed the core principal of a flat
heirarchy was more
important than avoiding unneccessary inheritance. Second,
what should be
the behaviour if both a fileset and a viewpath were
specified. Some ant
tasks look at the two types of arguments as mutually
exclusive. Other tasks
looks at them as additive. I decided to look at them at
additive. It just
seemed to maximize the flexibility of the end user while
simplifying the
code.
I didn't know what was appropriate for updates to the documentation.
I figured a short paragraph in the manual to the effect of:
The cccheckout task supports a nested <a href="
http://ant.apache.org/manual/using.html#path";>FileSet</a> or DirSet
element.
With a sample task like:
<cccheckout reserved="true">
<fileset dir="${generate.src}">
<include name="**/*.java"/>
<exclude name="**/Log.java"/>
</fileset>
</cccheckout>
I'd really like to see this enhancement get committed into
the code base.
If there is some more work I should do to help with that
goal, please let
me know. I'm still testing the tasks and getting them
integrated into our
process, but wanted to contact you before I got too far into
it in case you
had some suggestions on the implementation. Can somebody
please review and
commit as appropriate?
Thanks,
Jason Smith
Zurich Insurance
******************* PLEASE NOTE *******************
This E-Mail/telefax message and any documents accompanying this
transmission may contain privileged and/or confidential
information and is
intended solely for the addressee(s) named above. If you are not the
intended addressee/recipient, you are hereby notified that any use of,
disclosure, copying, distribution, or reliance on the contents of this
E-Mail/telefax information is strictly prohibited and may
result in legal
action against you. Please reply to the sender advising of
the error in
transmission and immediately delete/destroy the message and any
accompanying documents. Thank you.
******************* PLEASE NOTE *******************
This E-Mail/telefax message and any documents accompanying this
transmission may contain privileged and/or confidential
information and is
intended solely for the addressee(s) named above. If you are not the
intended addressee/recipient, you are hereby notified that any use of,
disclosure, copying, distribution, or reliance on the contents of this
E-Mail/telefax information is strictly prohibited and may
result in legal
action against you. Please reply to the sender advising of
the error in
transmission and immediately delete/destroy the message and any
accompanying documents. Thank you.
