Once asked is enough - you´ll writing to a complete mailinglist ... Jan
>-----Ursprüngliche Nachricht----- >Von: Srinivas [mailto:[EMAIL PROTECTED] >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:[EMAIL PROTECTED] >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:[EMAIL PROTECTED] > > 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:[EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > >********************************************************* >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: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
