And for such questions you are using the wrong list: dev (at) ant.apache.org is for devoping Ant itself user (at) ant.apache.org is for question users of Ant (like yours)
Jan >-----Ursprüngliche Nachricht----- >Von: Martin Gainty [mailto:[EMAIL PROTECTED] >Gesendet: Donnerstag, 9. Juni 2005 15:04 >An: Ant Developers List >Betreff: Re: Can you help me!!! > >Srinivas: >As a matter of common courtesy: >1)We do not hike other people's mail conversation thread to >promote our own >agenda >2)We send mail to group instead of to individual(s) who >contribute to any >list >Doing the former is considered rude behaviour >Doing the latter is considered disrepectful if the individual you are >addressing has not emailed you previously- >Regards, >Martin- >----- Original Message ----- >From: "Srinivas" <[EMAIL PROTECTED]> >To: "Ant Developers List" <dev@ant.apache.org> >Sent: Thursday, June 09, 2005 6:22 AM >Subject: 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
