No need for a new task... Ant provides a whole host of generic tasks that you can string together in a script to address a large number of problem domains.
Please note that this sort request should be addressed to the user list rather than the developer list. Phil On Thu, 2005-06-09 at 17:37 +0530, Srinivas wrote: > 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]
