You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Scott Stirling <sc...@rcn.com> on 2002/12/01 02:37:45 UTC
Ant Perversions [was RE: Properties are causing problem in 1.5]
I've intentionally sensationalized the subject. Don't be offended.
Why use Ant for things like telnet, VSS, .NET, looping scripts, etc.? I'm
all for Ant as a build tool and tool for general development-related Java
stuff like deploying apps or running command line, non-interactive, Java
tools. But Ant's lousy for working with interactive programs, controlling
GUIs, and anything requiring complex flow control logic. People in denial
of this fundamental truth will do anything to compensate for Ant's
limitations.
I've found tools such as sed, grep, and expect, not to mention the benefits
of UNIX shell scripting, to be indispensable assistants to cross-platform
builds, whether it's for scheduling builds in a platform-neutral way, or
customizing reports output from 3rd party tools (like StarTeam diff), or
launching native OS tools like load test tools after a build is deployed.
My answer for platform portability (at least Win32 to UNIX) is Cygwin on
Windows and basic tools on UNIX. 90% or more of the builds are done in Ant,
but things like build scheduling, disk mounting, interactive stuff (telnet),
and post-processing text data in an automated way are done outside of Ant
where there are plenty of pre-Ant tools making this stuff fast and easy to
do. NOTE: I did ask on the sed-users for a Java version of sed and got no
reply -- an interesting idea for a Java open source opportunity, IMO).
Some people want Ant to do everything (or want to do everything from within
Ant), in hopes of achieving portability perfection in a cross-platform
world, even at the expense of horrible hacks in custom tasks, or tying the
build to OS-specific tools through <apply/> or <exec/>.
Is the sense of where to draw the line and admit Ant's limitations a matter
of taste? Experience? Laziness? Or what?
Best,
Scott Stirling
> -----Original Message-----
> From: andrew sliwkowski [mailto:asliwk@bea.com]
> Sent: Saturday, November 30, 2002 3:09 PM
> To: Ant Users List
> Subject: RE: Properties are causing problem in 1.5
>
>
> Does anybody have an example of using foreach(2) with parallel?
> We are trying to automate installs of 1-15 machines... Today we basically
> get the list of machines we need to remotely install .. and
> iterate with the
> foreach2 task ...
> which invokes a telnet task which does the remote install... the
> problem is
> that the install takes 10 mins or so to complete..... so we end
> up with upto
> 150 minute wait before we can start the test(s)....
>
> thanks much in advance.
> /drew
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Ant Perversions [was RE: Properties are causing problem in 1.5]
Posted by Jim Krygowski <ja...@shaws.com>.
Cruise Control has been improved over the last year or so. Release 2.x is
quite good and incorporates xml configuration files and the ability to
integrate with your ant build.xml files with little or no modification to
those build files necessary.
> -----Original Message-----
> From: Steve Loughran [mailto:steve_l@iseran.com]
> Sent: Monday, December 02, 2002 3:02 PM
> To: Ant Users List; scottstirling@rcn.com
> Subject: Re: Ant Perversions [was RE: Properties are causing problem in
> 1.5]
>
>
>
> ----- Original Message -----
> From: "Scott Stirling" <sc...@rcn.com>
> To: "Ant Users List" <an...@jakarta.apache.org>
> Sent: Sunday, December 01, 2002 15:20
> Subject: RE: Ant Perversions [was RE: Properties are causing
> problem in 1.5]
>
>
>
> > Yeah, but why call them from Ant? It makes more sense to me to call Ant
> > from a shell script, calling targets and feeding it parameters,
> instead of
> > vice-versa. That's how Ant gets started up from $ANT_HOME/bin
> anyway. As
> > soon as you're inside Ant world you lose things like return codes,
> streaming
> > text editors and easy piping from one command to another. The new
> > FilterChains in Ant are very cool, but you have to write, compile and
> > package custom Java code for multi-line edit one-offs that sed
> and grep or
> > perl can do in 1-4 lines of code (granted, sed and perl require
> their own
> > environments to run (well, standalone (non-Cygwin) sed and grep can be
> > obtained for Windows), but aren't things like sed and perl at least as
> > widely available, even on Windows, as Ant and a 1.3 JDK?)
>
> activestate perl is very god; has com object control too. But we do need a
> sed task in ant, somehow.
>
> >. However, it may be worth
> > revisiting to see if CruiseControl provides some other benefits he's
> > overlooking.
>
> It has a well founded reputation as being a dog to set up, but I
> hear it is
> improving.
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Ant Perversions [was RE: Properties are causing problem in 1.5]
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Scott Stirling" <sc...@rcn.com>
To: "Ant Users List" <an...@jakarta.apache.org>
Sent: Sunday, December 01, 2002 15:20
Subject: RE: Ant Perversions [was RE: Properties are causing problem in 1.5]
> Yeah, but why call them from Ant? It makes more sense to me to call Ant
> from a shell script, calling targets and feeding it parameters, instead of
> vice-versa. That's how Ant gets started up from $ANT_HOME/bin anyway. As
> soon as you're inside Ant world you lose things like return codes,
streaming
> text editors and easy piping from one command to another. The new
> FilterChains in Ant are very cool, but you have to write, compile and
> package custom Java code for multi-line edit one-offs that sed and grep or
> perl can do in 1-4 lines of code (granted, sed and perl require their own
> environments to run (well, standalone (non-Cygwin) sed and grep can be
> obtained for Windows), but aren't things like sed and perl at least as
> widely available, even on Windows, as Ant and a 1.3 JDK?)
activestate perl is very god; has com object control too. But we do need a
sed task in ant, somehow.
>. However, it may be worth
> revisiting to see if CruiseControl provides some other benefits he's
> overlooking.
It has a well founded reputation as being a dog to set up, but I hear it is
improving.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Ant Perversions [was RE: Properties are causing problem in 1.5]
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
Scott Stirling wrote:
>>>tools out there like Flux. Would that appropriate for scheduling builds
>>>either from Ant or around Ant? How do others automate Ant builds in
>>>cross-platform environments? Cron on UNIX/AT on WIndows?
>>
>>anthill, cruisecontrol. AT sucks.
>
>
> I haven't tried AntHill, but a colleague of mine tried CruiseControl
> recently. Unfortunately, he already had automated the StarTeam checking
> out, diffing, emailing, etc. via Ant, so the overhead of configuring and
> running CruiseControl just to use it as a dumb scheduler to run a
> self-sufficient build file seemed ridiculous. However, it may be worth
> revisiting to see if CruiseControl provides some other benefits he's
> overlooking.
Anthill rocks. Its far far easier to configure than CruiseControl and
runs entirely as web application within a lightweight container like Tomcat.
Have your colleague give Anthill a try and compare to your own
hand-rolled automation and the effort to get CruiseControl working.
Erik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Ant Perversions [was RE: Properties are causing problem in 1.5]
Posted by Scott Stirling <sc...@rcn.com>.
> -----Original Message-----
> From: Steve Loughran [mailto:steve_l@iseran.com]
[...]
> > Some people want Ant to do everything (or want to do everything from
> > within Ant), in hopes of achieving portability perfection in a
> > cross-platform world, even at the expense of horrible hacks in custom
> > tasks, or tying the build to OS-specific tools through <apply/> or
> > <exec/>.
>
> what if you are execing or applying a perl script or a gnu command? You
> arent totally tied down there.
Yeah, but why call them from Ant? It makes more sense to me to call Ant
from a shell script, calling targets and feeding it parameters, instead of
vice-versa. That's how Ant gets started up from $ANT_HOME/bin anyway. As
soon as you're inside Ant world you lose things like return codes, streaming
text editors and easy piping from one command to another. The new
FilterChains in Ant are very cool, but you have to write, compile and
package custom Java code for multi-line edit one-offs that sed and grep or
perl can do in 1-4 lines of code (granted, sed and perl require their own
environments to run (well, standalone (non-Cygwin) sed and grep can be
obtained for Windows), but aren't things like sed and perl at least as
widely available, even on Windows, as Ant and a 1.3 JDK?)
> > Is the sense of where to draw the line and admit Ant's limitations a
> > matter of taste? Experience? Laziness? Or what?
>
> Maybe we just like the idea of doing everything in java?
I empathize with you there. But because Java's inherently abstracted from
everything else (OS, native tools, UNIX tools), it's a PITA to integrate it
with anything lacking a Java API if you try to do it from inside Java rather
than the other way 'round.
> > The scheduling limitation is kind of a big one. There are Java
scheduling
> > tools out there like Flux. Would that appropriate for scheduling builds
> > either from Ant or around Ant? How do others automate Ant builds in
> > cross-platform environments? Cron on UNIX/AT on WIndows?
>
> anthill, cruisecontrol. AT sucks.
I haven't tried AntHill, but a colleague of mine tried CruiseControl
recently. Unfortunately, he already had automated the StarTeam checking
out, diffing, emailing, etc. via Ant, so the overhead of configuring and
running CruiseControl just to use it as a dumb scheduler to run a
self-sufficient build file seemed ridiculous. However, it may be worth
revisiting to see if CruiseControl provides some other benefits he's
overlooking.
Best,
Scott Stirling
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Ant Perversions [was RE: Properties are causing problem in 1.5]
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Scott Stirling" <sc...@rcn.com>
To: "Ant Users List" <an...@jakarta.apache.org>
Sent: Saturday, November 30, 2002 17:37
Subject: Ant Perversions [was RE: Properties are causing problem in 1.5]
> I've intentionally sensationalized the subject. Don't be offended.
too late :)
> Why use Ant for things like telnet, VSS, .NET, looping scripts, etc.? I'm
> all for Ant as a build tool and tool for general development-related Java
> stuff like deploying apps or running command line, non-interactive, Java
> tools. But Ant's lousy for working with interactive programs, controlling
> GUIs, and anything requiring complex flow control logic. People in denial
> of this fundamental truth will do anything to compensate for Ant's
> limitations.
I dont loop. But I use <telnet> for remote deployment, shortly before I run
my httpunit tests. But all I telnet is the command to invoke the ant file I
have have just uploaded, a build file to deploy on the target app server a
properties file tells me is on that system. So it aint that complex at all;
though a better remote ant api would be nice, even though ops would through
a wobbly at the idea.
> NOTE: I did ask on the sed-users for a Java version of sed and got no
> reply -- an interesting idea for a Java open source opportunity, IMO).
for all its ugliness, sed has a place.
>
> Some people want Ant to do everything (or want to do everything from
within
> Ant), in hopes of achieving portability perfection in a cross-platform
> world, even at the expense of horrible hacks in custom tasks, or tying the
> build to OS-specific tools through <apply/> or <exec/>.
what if you are execing or applying a perl script or a gnu command? You
arent totally tied down there.
> Is the sense of where to draw the line and admit Ant's limitations a
matter
> of taste? Experience? Laziness? Or what?
Maybe we just like the idea of doing everything in java?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Ant Perversions [was RE: Properties are causing problem in 1.5]
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Scott Stirling" <sc...@rcn.com>
To: "Ant Users List" <an...@jakarta.apache.org>
Sent: Saturday, November 30, 2002 18:49
Subject: RE: Ant Perversions [was RE: Properties are causing problem in 1.5]
> Hi,
>
>
> Cygwin is free and kinda lightweight; UNIX is everywhere.
but ops hate adding more stuff to their boxes than they can, and if it aint
a unix box, trying to get them to put cygwin on is trouble. Plus cygwin is
troublesome too at times.
It's when you're setting up the product's fully
> automated cross-platform build/test/report/install, etc. cycle that
> post-processes external tools' output, generates better email reports than
> Ant's mail logger, configures and runs some MS tool, needs to be
scheduled,
> or set-up quickly and easily on multiple (UNIX and Windows) machines that
I
> start reaching for other tools in the bag.
we use perl for this :)
> The scheduling limitation is kind of a big one. There are Java scheduling
> tools out there like Flux. Would that appropriate for scheduling builds
> either from Ant or around Ant? How do others automate Ant builds in
> cross-platform environments? Cron on UNIX/AT on WIndows?
anthill, cruisecontrol. AT sucks.
> Scott Stirling
>
> > -----Original Message-----
> > From: Martin [mailto:mgainty@hotmail.com]
> > Sent: Wednesday, May 01, 2002 7:29 PM
> > To: Ant Users List; scottstirling@rcn.com
> > Subject: Re: Ant Perversions [was RE: Properties are causing problem in
> > 1.5]
> >
> >
> > Scott:
> > I think you are forgetting why developers choose Ant consistently
> > for their
> > build environments...
> > 1)it is truly portable..I can plunk my build.xml into a different
> > development environment with no ill effect ..can you say the same
> > for ANY of
> > your platform specific tools..Can they read and adjust their environment
> > completely based on
> > a few property files and environment variables?
> > 2)It is free..This makes ant available for all to use..Some IDE's
> > have hiked
> > their price
> > from anywhere between 500-1000$ Why because they are incorporating free
> > tools that you and I have used for free for years..Ants use of the
> > exec/apply and java commands can call or execute the majority of
> > these free
> > tools without incurring the weight and slow speed of an IDE
> > 3)It is lightweight..simply because a developer has the ability
respecify
> > Java_home and thus javac and java tools..How many tools have the
> > ability to
> > dynamically reconfigure itself to changing environment..Most tools I
have
> > seen are static in nature.
> > 4)We have real techs working on Ant who use the product they are
> > developing..this frees us developers from talking to annoying
salespeople
> > pushing IDEs that re slow and resource/memory hogs.
> > I have just given you 4 good reasons for using Ant..
> > Can any of the tools you have mentioned claim to have ALL 4 of the
> > aforementioned benefits..I know that make cant send mail, cant create
> > javadoc and cannot create testcases and run them so the answer to the
> > question is
> > I doubt it..
> > -Martin
> > ----- Original Message -----
> > From: "Scott Stirling" <sc...@rcn.com>
> > To: "Ant Users List" <an...@jakarta.apache.org>
> > Sent: Saturday, November 30, 2002 9:37 PM
> > Subject: Ant Perversions [was RE: Properties are causing problem in 1.5]
> >
> >
> > > I've intentionally sensationalized the subject. Don't be offended.
> > >
> > > Why use Ant for things like telnet, VSS, .NET, looping scripts,
> > etc.? I'm
> > > all for Ant as a build tool and tool for general
> > development-related Java
> > > stuff like deploying apps or running command line, non-interactive,
Java
> > > tools. But Ant's lousy for working with interactive programs,
> > controlling
> > > GUIs, and anything requiring complex flow control logic.
> > People in denial
> > > of this fundamental truth will do anything to compensate for Ant's
> > > limitations.
> > >
> > > I've found tools such as sed, grep, and expect, not to mention the
> > benefits
> > > of UNIX shell scripting, to be indispensable assistants to
> > cross-platform
> > > builds, whether it's for scheduling builds in a platform-neutral way,
or
> > > customizing reports output from 3rd party tools (like StarTeam diff),
or
> > > launching native OS tools like load test tools after a build is
> > deployed.
> > > My answer for platform portability (at least Win32 to UNIX) is Cygwin
on
> > > Windows and basic tools on UNIX. 90% or more of the builds are done
in
> > Ant,
> > > but things like build scheduling, disk mounting, interactive stuff
> > (telnet),
> > > and post-processing text data in an automated way are done
> > outside of Ant
> > > where there are plenty of pre-Ant tools making this stuff fast
> > and easy to
> > > do. NOTE: I did ask on the sed-users for a Java version of sed
> > and got no
> > > reply -- an interesting idea for a Java open source opportunity, IMO).
> > >
> > > Some people want Ant to do everything (or want to do everything from
> > within
> > > Ant), in hopes of achieving portability perfection in a cross-platform
> > > world, even at the expense of horrible hacks in custom tasks,
> > or tying the
> > > build to OS-specific tools through <apply/> or <exec/>.
> > >
> > > Is the sense of where to draw the line and admit Ant's limitations a
> > matter
> > > of taste? Experience? Laziness? Or what?
> > >
> > > Best,
> > > Scott Stirling
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Ant Perversions [was RE: Properties are causing problem in 1.5]
Posted by Scott Stirling <sc...@rcn.com>.
Hi,
I've been using Ant for a few years for all the reasons you listed below.
My question isn't "why use Ant?" -- but more like "at what point should one
admit Ant's limitations and augment it?"
Cygwin is free and kinda lightweight; UNIX is everywhere. That's why I
usually wrap a lot of heavy-duty build stuff in shell scripts where Ant is a
large, but not the only, part of the picture. I'm talking about major
infrastructure work. This doesn't mean that for your desktop, dinky build
stuff like compile/jar/junit/report/deploy I don't use or recommend pure
Ant. I do, totally. It's when you're setting up the product's fully
automated cross-platform build/test/report/install, etc. cycle that
post-processes external tools' output, generates better email reports than
Ant's mail logger, configures and runs some MS tool, needs to be scheduled,
or set-up quickly and easily on multiple (UNIX and Windows) machines that I
start reaching for other tools in the bag.
The scheduling limitation is kind of a big one. There are Java scheduling
tools out there like Flux. Would that appropriate for scheduling builds
either from Ant or around Ant? How do others automate Ant builds in
cross-platform environments? Cron on UNIX/AT on WIndows?
Scott Stirling
> -----Original Message-----
> From: Martin [mailto:mgainty@hotmail.com]
> Sent: Wednesday, May 01, 2002 7:29 PM
> To: Ant Users List; scottstirling@rcn.com
> Subject: Re: Ant Perversions [was RE: Properties are causing problem in
> 1.5]
>
>
> Scott:
> I think you are forgetting why developers choose Ant consistently
> for their
> build environments...
> 1)it is truly portable..I can plunk my build.xml into a different
> development environment with no ill effect ..can you say the same
> for ANY of
> your platform specific tools..Can they read and adjust their environment
> completely based on
> a few property files and environment variables?
> 2)It is free..This makes ant available for all to use..Some IDE's
> have hiked
> their price
> from anywhere between 500-1000$ Why because they are incorporating free
> tools that you and I have used for free for years..Ants use of the
> exec/apply and java commands can call or execute the majority of
> these free
> tools without incurring the weight and slow speed of an IDE
> 3)It is lightweight..simply because a developer has the ability respecify
> Java_home and thus javac and java tools..How many tools have the
> ability to
> dynamically reconfigure itself to changing environment..Most tools I have
> seen are static in nature.
> 4)We have real techs working on Ant who use the product they are
> developing..this frees us developers from talking to annoying salespeople
> pushing IDEs that re slow and resource/memory hogs.
> I have just given you 4 good reasons for using Ant..
> Can any of the tools you have mentioned claim to have ALL 4 of the
> aforementioned benefits..I know that make cant send mail, cant create
> javadoc and cannot create testcases and run them so the answer to the
> question is
> I doubt it..
> -Martin
> ----- Original Message -----
> From: "Scott Stirling" <sc...@rcn.com>
> To: "Ant Users List" <an...@jakarta.apache.org>
> Sent: Saturday, November 30, 2002 9:37 PM
> Subject: Ant Perversions [was RE: Properties are causing problem in 1.5]
>
>
> > I've intentionally sensationalized the subject. Don't be offended.
> >
> > Why use Ant for things like telnet, VSS, .NET, looping scripts,
> etc.? I'm
> > all for Ant as a build tool and tool for general
> development-related Java
> > stuff like deploying apps or running command line, non-interactive, Java
> > tools. But Ant's lousy for working with interactive programs,
> controlling
> > GUIs, and anything requiring complex flow control logic.
> People in denial
> > of this fundamental truth will do anything to compensate for Ant's
> > limitations.
> >
> > I've found tools such as sed, grep, and expect, not to mention the
> benefits
> > of UNIX shell scripting, to be indispensable assistants to
> cross-platform
> > builds, whether it's for scheduling builds in a platform-neutral way, or
> > customizing reports output from 3rd party tools (like StarTeam diff), or
> > launching native OS tools like load test tools after a build is
> deployed.
> > My answer for platform portability (at least Win32 to UNIX) is Cygwin on
> > Windows and basic tools on UNIX. 90% or more of the builds are done in
> Ant,
> > but things like build scheduling, disk mounting, interactive stuff
> (telnet),
> > and post-processing text data in an automated way are done
> outside of Ant
> > where there are plenty of pre-Ant tools making this stuff fast
> and easy to
> > do. NOTE: I did ask on the sed-users for a Java version of sed
> and got no
> > reply -- an interesting idea for a Java open source opportunity, IMO).
> >
> > Some people want Ant to do everything (or want to do everything from
> within
> > Ant), in hopes of achieving portability perfection in a cross-platform
> > world, even at the expense of horrible hacks in custom tasks,
> or tying the
> > build to OS-specific tools through <apply/> or <exec/>.
> >
> > Is the sense of where to draw the line and admit Ant's limitations a
> matter
> > of taste? Experience? Laziness? Or what?
> >
> > Best,
> > Scott Stirling
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Ant Perversions [was RE: Properties are causing problem in 1.5]
Posted by Martin <mg...@hotmail.com>.
Scott:
I think you are forgetting why developers choose Ant consistently for their
build environments...
1)it is truly portable..I can plunk my build.xml into a different
development environment with no ill effect ..can you say the same for ANY of
your platform specific tools..Can they read and adjust their environment
completely based on
a few property files and environment variables?
2)It is free..This makes ant available for all to use..Some IDE's have hiked
their price
from anywhere between 500-1000$ Why because they are incorporating free
tools that you and I have used for free for years..Ants use of the
exec/apply and java commands can call or execute the majority of these free
tools without incurring the weight and slow speed of an IDE
3)It is lightweight..simply because a developer has the ability respecify
Java_home and thus javac and java tools..How many tools have the ability to
dynamically reconfigure itself to changing environment..Most tools I have
seen are static in nature.
4)We have real techs working on Ant who use the product they are
developing..this frees us developers from talking to annoying salespeople
pushing IDEs that re slow and resource/memory hogs.
I have just given you 4 good reasons for using Ant..
Can any of the tools you have mentioned claim to have ALL 4 of the
aforementioned benefits..I know that make cant send mail, cant create
javadoc and cannot create testcases and run them so the answer to the
question is
I doubt it..
-Martin
----- Original Message -----
From: "Scott Stirling" <sc...@rcn.com>
To: "Ant Users List" <an...@jakarta.apache.org>
Sent: Saturday, November 30, 2002 9:37 PM
Subject: Ant Perversions [was RE: Properties are causing problem in 1.5]
> I've intentionally sensationalized the subject. Don't be offended.
>
> Why use Ant for things like telnet, VSS, .NET, looping scripts, etc.? I'm
> all for Ant as a build tool and tool for general development-related Java
> stuff like deploying apps or running command line, non-interactive, Java
> tools. But Ant's lousy for working with interactive programs, controlling
> GUIs, and anything requiring complex flow control logic. People in denial
> of this fundamental truth will do anything to compensate for Ant's
> limitations.
>
> I've found tools such as sed, grep, and expect, not to mention the
benefits
> of UNIX shell scripting, to be indispensable assistants to cross-platform
> builds, whether it's for scheduling builds in a platform-neutral way, or
> customizing reports output from 3rd party tools (like StarTeam diff), or
> launching native OS tools like load test tools after a build is deployed.
> My answer for platform portability (at least Win32 to UNIX) is Cygwin on
> Windows and basic tools on UNIX. 90% or more of the builds are done in
Ant,
> but things like build scheduling, disk mounting, interactive stuff
(telnet),
> and post-processing text data in an automated way are done outside of Ant
> where there are plenty of pre-Ant tools making this stuff fast and easy to
> do. NOTE: I did ask on the sed-users for a Java version of sed and got no
> reply -- an interesting idea for a Java open source opportunity, IMO).
>
> Some people want Ant to do everything (or want to do everything from
within
> Ant), in hopes of achieving portability perfection in a cross-platform
> world, even at the expense of horrible hacks in custom tasks, or tying the
> build to OS-specific tools through <apply/> or <exec/>.
>
> Is the sense of where to draw the line and admit Ant's limitations a
matter
> of taste? Experience? Laziness? Or what?
>
> Best,
> Scott Stirling
>
>
> > -----Original Message-----
> > From: andrew sliwkowski [mailto:asliwk@bea.com]
> > Sent: Saturday, November 30, 2002 3:09 PM
> > To: Ant Users List
> > Subject: RE: Properties are causing problem in 1.5
> >
> >
> > Does anybody have an example of using foreach(2) with parallel?
> > We are trying to automate installs of 1-15 machines... Today we
basically
> > get the list of machines we need to remotely install .. and
> > iterate with the
> > foreach2 task ...
> > which invokes a telnet task which does the remote install... the
> > problem is
> > that the install takes 10 mins or so to complete..... so we end
> > up with upto
> > 150 minute wait before we can start the test(s)....
> >
> > thanks much in advance.
> > /drew
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>