ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Weighill Smith <phil.weighill-sm...@volantis.com>
Subject RE: Can you help me!!!
Date Thu, 09 Jun 2005 13:39:57 GMT
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:phil.weighill-smith@volantis.com]
> 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:phil.weighill-smith@volantis.com]
> > 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:Sandip.Chitale@Sun.COM]
> > 	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:Sandip.Chitale@Sun.COM]
> > 	>       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: dev-unsubscribe@ant.apache.org
> > 	For additional commands, e-mail: dev-help@ant.apache.org
> >
> >
> >
> >
> >
> > *********************************************************
> > 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: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
> >
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
> 
> 
> 
> *********************************************************
> 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: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message