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]
