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: Can you help me!!!
Date Thu, 09 Jun 2005 11:30:08 GMT
Once asked is enough - you┬┤ll writing to a complete mailinglist ...

Jan 

>-----Urspr├╝ngliche Nachricht-----
>Von: Srinivas [mailto:csrini@mahindrabt.com] 
>Gesendet: Donnerstag, 9. Juni 2005 12:23
>An: Ant Developers List
>Betreff: Can you help me!!!
>
>
>Dear Smith,
>
> 	I am new to ant Scripting.  My requirement is like 
>this.  We are using Weblogic.
>
>         I receive an .EAR file and before deployment my BUILD 
>should do the following.
>	
>
>		a. My Script should locate the 
>weblogic-ejb-jar.xml inside the .EAR and 
><trans-time-out></trans-time-out>
>		   Element should be modified per EJB basis.
>
>	What do you suggest?
>	
>
>Regards,
>Srini.
>
>-----Original Message-----
>From: Phil Weighill-Smith [mailto:phil.weighill-smith@volantis.com]
>Sent: Sunday, May 29, 2005 8:42 PM
>To: Ant Developers List
>Subject: RE: A possible solution for conditional execution of tasks?
>
>
>There is the option to use the conditional task ("if") from 
>ant-contrib... this allows the nesting of a "sequential" task 
>which itself can contain any tasks you want.
>
>	-----Original Message-----
>
>	From: Sandip Chitale [mailto:Sandip.Chitale@Sun.COM]
>
>	Sent: Sun 29/05/2005 16:06
>
>	To: Ant Developers List
>
>	Cc:
>
>	Subject: Re: A possible solution for conditional 
>execution of tasks?
>
>
>
>
>
>	Phil Weighill-Smith wrote:
>
>
>	>My opinion regarding the disadvantages of this approach:
>	>
>	>*      Antcall has to create a whole new Project in 
>memory in order to work and is therefore an inefficient task
>	>
>
>	>
>	Yes. If the project is large this could be a large 
>overhead. It seems
>	the semantics of antcall is not like a sub target but 
>more like a target
>	in a sub project (even though the project happens to be the same
>	project).  Is there a more lightweight solution planned 
>in this area?
>
>
>	>*      If something invoked via Antcall depends on a 
>target that is also depended on by something depending on the 
>target invoking Antcall then this dependency target will be 
>executed more than once because dependencies are not handled 
>across Antcall invocations
>	>
>
>	>
>	Yes.
>
>
>	>*      The dependency tree is "interrupted" and 
>graphing tools that can show ant build script structures will 
>not (generally) work correctly and show the whole dependency tree
>	>
>
>	>
>	I did not think about the graphing tools, but that is a 
>good point also.
>
>
>	Given the fact that you did not list any advantages it 
>seems this is not
>	a good idea.
>
>
>	>It might be better to add "if" and "unless" to the 
>standard ant Task to allow for conditional execution, or even 
>add a nested "condition" to the standard ant Task to allow for 
>conditional execution. To provide BC with the standard 
>"execute" method, the condition/if/unless processing would 
>need to happen outside this method.
>	>
>
>	>
>	This seems like this is the real answer. However I read 
>somewhere that
>	it is an architectural decision to not support "if" and 
>"unless" etc. at
>	the task level. Can anyone point me to a 
>discussion/document on that?
>
>
>	What about using scripting? Is that not recommended either?
>
>
>	Google search revealed that many people are looking for 
>solutions for
>	similar problems.
>
>
>	Regards,
>	Sandip
>
>
>	>
>	>Phil :n.
>	>
>	>       -----Original Message-----
>	>       From: Sandip Chitale [mailto:Sandip.Chitale@Sun.COM]
>	>       Sent: Sat 28/05/2005 18:56
>	>       To: dev@ant.apache.org
>	>       Cc:
>	>       Subject: A possible solution for conditional 
>execution of tasks?
>	>     
>
>	>     
>
>	>
>	>       To conditionally execute a step in Ant one has 
>to resort to setting up a
>	>       target structure like this:
>	>     
>
>	>       :
>	>       <target name="predicate">
>	>          <condition property="condition-satisfied">
>	>              <available .../>
>	>          :
>	>          </condition>
>	>       </target>
>	>     
>
>	>       <target name="conditional-step" 
>if="condition-satisfied">
>	>          <!-- conditional tasks here -->
>	>          :
>	>          :
>	>       </target>
>	>     
>
>	>       <target name="conditional" depends="predicate, 
>conditional-step"/>
>	>     
>
>	>       <target name="main" depends="conditional">
>	>          :
>	>          :
>	>       </target>
>	>       :
>	>     
>
>	>       This is because of several reasons:
>	>     
>
>	>           * The ant tasks do not have something like 
>*if* attribute.
>	>           * One cannot get away with only two targets 
>instead of three because
>	>             the dependencies are executed before the 
>dependent. Using the
>	>             above example it is not possible to do 
>what target predicate does
>	>             in the main target and avoid using the 
>predicate target.
>	>           * Ensure order of execution
>	>     
>
>	>       However, I tried a solution making use of 
>antcall task and it worked. It
>	>       works as follows:
>	>     
>
>	>       :
>	>       <target name="conditional-step" 
>if="condition-satisfied">
>	>          <!-- conditional tasks here -->
>	>          :
>	>          :
>	>       </target>
>	>     
>
>	>       <target name="main" depends="conditional-step">
>	>       :
>	>          <condition property="condition-satisfied">
>	>              <available .../>
>	>          :
>	>          </condition>
>	>          <antcall target="condition-satisfied"/>
>	>          :
>	>       </target>
>	>     
>
>	>       The advantage of this approach is to quickly 
>have some tasks execute
>	>       conditionally by putting them in a target and 
>calling that target using
>	>       antcall after setting some property.
>	>     
>
>	>       And it seemed to work. My question is - is 
>there a problem using this
>	>       approach? Why or why isn't this a preferred approach?
>	>     
>
>	>       Thanks in advance,
>	>       Sandip
>	>     
>
>	>     
>
>	>
>	>
>
>	>
>
>
>
>
>	
>---------------------------------------------------------------------
>	To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>	For additional commands, e-mail: dev-help@ant.apache.org
>
>
>
>
>
>
>
>*********************************************************
>Disclaimer:
>
>The contents of this E-mail (including the contents of the 
>enclosure(s) or attachment(s) if any) are privileged and 
>confidential material of MBT and should not be disclosed to, 
>used by or copied in any manner by anyone other than the 
>intended addressee(s).   In case you are not the desired 
>addressee, you should delete this message and/or re-direct it 
>to the sender.  The views expressed in this E-mail message 
>(including the enclosure(s) or attachment(s) if any) are those 
>of the individual sender, except where the sender expressly, 
>and with authority, states them to be the views of MBT.
>
>This e-mail message including attachment/(s), if any, is 
>believed to be free of any virus.  However, it is the 
>responsibility of the recipient to ensure that it is virus 
>free and MBT is not responsible for any loss or damage arising 
>in any way from its use
>
>*********************************************************
>
>---------------------------------------------------------------------
>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