ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Jan.Mate...@rzf.fin-nrw.de>
Subject AW: Ant Clearcase tasks
Date Wed, 03 Aug 2005 08:48:31 GMT
Would a more general solution be better?
A <ischeckedout> selector?

<ischeckedout scm="clearcase|svn|cvs|..."/> which delegates to the scm-specific class.


Jan 

>-----Urspr√ľngliche Nachricht-----
>Von: Steve Loughran [mailto:stevel@apache.org] 
>Gesendet: Mittwoch, 3. August 2005 10:44
>An: Ant Developers List
>Betreff: Re: Ant Clearcase tasks
>
>Anderson, Rob (Global Trade) wrote:
>> Jason, I am still using Ant, and I am still using ClearCase. 
>While we currently are not using the ClearCase Ant Tasks, we 
>perhaps will be using them in the future. Your enhancements 
>are quite interesting. I have a new ClearCase related Ant 
>feature that you might be interested in: A ClearCase lsco 
>FileSet selector, that can select files in a ClearCase view 
>that are currently checked out. The code is working and 
>complete, however there are some things I need to do in order 
>to clean it up before it would be ready to commit. As it turns 
>out, Curtis White, one of the original authors of some of the 
>ClearCase tasks, is a coworker of mine. I believe he is 
>responsible for the checkin and checkout tasks. I might be 
>able to enlist him in reviewing the enhancements you have proposed.
>> 
>> Ant Committers: Is this something you would consider commiting?
>> 
>> -Rob Anderson
>> 
>
>If the clearcase users are all happy with the changes, then 
>yes, it goes in. Not having to deal with the dark and vengeful 
>deity that is clearcase, I am not in a position to test 
>anything myself. Test cases would go a long way in making the 
>commit easier, as it will make it easier for everyone who has 
>CC to verify that the changes work...
>
>-steve
>
>
>
>
>>>-----Original Message-----
>>>From: Jason Smith [mailto:jason.smith@zurichna.com]
>>>Sent: Tuesday, August 02, 2005 9:27 AM
>>>To: Rob.Anderson@nike.com
>>>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:    sean@cm-logic.com, Anderson.Rob@vectorscm.com,
>>>       spkane@genomatica.com, cwhite@aracnet.com
>>>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.
>>>
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For 
>additional 
>> commands, e-mail: dev-help@ant.apache.org
>> 
>> 
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For 
>additional commands, e-mail: dev-help@ant.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message