http://ant.apache.org/external.html#xmltask
Jan >-----Ursprüngliche Nachricht----- >Von: Srinivas [mailto:[EMAIL PROTECTED] >Gesendet: Donnerstag, 9. Juni 2005 14:07 >An: Ant Developers List >Betreff: RE: Can you help me!!! > > >No need of writing our own task??? > >As I said I am totally new, I started working with ant now. >What I understood is <xslt/> of ant do the necessary processing and >modifications. > >But if the value of this particular ><trans-time-out></trans-time-out> tag >varies from EJB to EJB then ???? > >srini. > >-----Original Message----- >From: Phil Weighill-Smith [mailto:[EMAIL PROTECTED] >Sent: Thursday, June 09, 2005 5:07 PM >To: Ant Developers List >Subject: Re: Can you help me!!! > > >Try using <unzip .../> to extract the XML file from the EAR then use ><xslt .../> to process and modify the XML file accordingly. Rename the >output file from the XSLT back to the original name (using <move .../>) >then use <zip ../> to put the file back in the EAR. > >Phil > >On Thu, 2005-06-09 at 15:52 +0530, Srinivas wrote: >> 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] > > > >********************************************************* >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]
