RE: Ant Perversions [was RE: Properties are causing problem in 1.5]
I've never used VSS, so I'll take your word for it. I hear it's a crummy SCM tool. Why do people use it? Believe me, I wonder how the hell StarTeam, which sucks compared to Perforce or even CVS IMNSHO, got entrenched at where I work. Happened before my time. That's exactly why people use VSS, I believe. Moving SCM is a big thing to do, I guess. The .NET tasks aren't necessarily interactive, or controlling GUIs or anything else. This has puzzled me for a while, so I might as well ask -- why if you are developing for .NET, which isn't cross-platform, would you use a Java tool to do your builds? Does .NET really not provide a quality set of build and automation tools? Or are they too expensive to buy? I don't get this one at all, but there must be a reason if .NET tasks made it into the optional task set. In fact, there's a .NET Ant project (Nant) but the reason is somewhat simpler than that, I believe: not all projects which involve .NET *only* involve .NET. We write stuff which is mostly cross-platform Java, but with also a Windows component and in the future a Compact Framework .NET component - having a single build procedure is a great help. If you could give better alternatives for all of the tasks which you think Ant is no good at, it would make your case a lot stronger. I thought I did -- grep, sed and sh are three ubiquitous tools that do stuff Ant's not good at (piping, stream editing, return codes, looping, no compilation or packaging necessary). I don't see how those are alternatives for .NET and VSS tasks though. They may help with telnet, but I can't see that they'd end up being significantly better to use than the existing telnet task which *doesn't* require installation of Cygwin. Jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Ant Perversions [was RE: Properties are causing problem in 1.5]
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:[EMAIL PROTECTED]] Sent: Monday, December 02, 2002 3:02 PM To: Ant Users List; [EMAIL PROTECTED] Subject: Re: Ant Perversions [was RE: Properties are causing problem in 1.5] - Original Message - From: Scott Stirling [EMAIL PROTECTED] To: Ant Users List [EMAIL PROTECTED] 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Ant Perversions [was RE: Properties are causing problem in 1.5]
- Original Message - From: Scott Stirling [EMAIL PROTECTED] To: Ant Users List [EMAIL PROTECTED] Sent: Sunday, December 01, 2002 15:32 Subject: RE: Ant Perversions [was RE: Properties are causing problem in 1.5] The .NET tasks aren't necessarily interactive, or controlling GUIs or anything else. This has puzzled me for a while, so I might as well ask -- why if you are developing for .NET, which isn't cross-platform, would you use a Java tool to do your builds? Does .NET really not provide a quality set of build and automation tools? Or are they too expensive to buy? I don't get this one at all, but there must be a reason if .NET tasks made it into the optional task set. yeah, I put them there. 1. NET ships with NMAKE, which is not a real make. 2. There is now NANT, but it is emerging 3. But the way I use the .net tasks is to do interop testing of web services; get the WSDL, turn the WSDL to C# stubs, code the test classes, run them. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: 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. In the build procedure at work, due to historical reasons I *only* use Ant for VSS work - simply because it's much better at getting the job done than anything else is, and *much* better than hand labelling lots of projects. The .NET tasks aren't necessarily interactive, or controlling GUIs or anything else. Similarly telnet is fine when it's doing *exactly* what you expect it to - and the build can fail if you don't get the response you're expecting. If you could give better alternatives for all of the tasks which you think Ant is no good at, it would make your case a lot stronger. Jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Ant Perversions [was RE: Properties are causing problem in 1.5]
-Original Message- From: Steve Loughran [mailto:[EMAIL PROTECTED]] [...] 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Ant Perversions [was RE: Properties are causing problem in 1.5]
-Original Message- From: Jon Skeet [mailto:[EMAIL PROTECTED]] [...] In the build procedure at work, due to historical reasons I *only* use Ant for VSS work - simply because it's much better at getting the job done than anything else is, and *much* better than hand labelling lots of projects. I've never used VSS, so I'll take your word for it. I hear it's a crummy SCM tool. Why do people use it? Believe me, I wonder how the hell StarTeam, which sucks compared to Perforce or even CVS IMNSHO, got entrenched at where I work. Happened before my time. The .NET tasks aren't necessarily interactive, or controlling GUIs or anything else. This has puzzled me for a while, so I might as well ask -- why if you are developing for .NET, which isn't cross-platform, would you use a Java tool to do your builds? Does .NET really not provide a quality set of build and automation tools? Or are they too expensive to buy? I don't get this one at all, but there must be a reason if .NET tasks made it into the optional task set. Similarly telnet is fine when it's doing *exactly* what you expect it to - and the build can fail if you don't get the response you're expecting. That's cool, and I think a Java implementation of telnet is used anyway in Ant. If you could give better alternatives for all of the tasks which you think Ant is no good at, it would make your case a lot stronger. I thought I did -- grep, sed and sh are three ubiquitous tools that do stuff Ant's not good at (piping, stream editing, return codes, looping, no compilation or packaging necessary). Scott Stirling -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Ant Perversions [was RE: Properties are causing problem in 1.5]
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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
-Original Message-
From: Geoff Meakin [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 24, 2002 5:58 AM
To: Ant Users List
Subject: RE: Properties are causing problem in 1.5
This looks like the same problem I had when designing foreach2
See http://www.geoff-meakin.com/antattack.html
Basically you have the trouble because the first time a Task
is performed, it maybeConfigures its environment (see
RuntimeConfigurable and ProjectHelper.configure) which overrides
the values of your XMLattributes with the correct property
substitutions. Now because thats already been done, if you try
and do it a second time with the same Task, the properties dont
get reset.
I had to override the RuntimeConfigurable in ANTCore to get this
working. If it helps, look at the sourcecode which I provide on
the website which fixes this problem. If it helps use the
foreach2 task jar, because it does what I believe you're trying
to do anyway.
See what you think
Cheers
-Geoff
-Original Message-
From: Mark R. Diggory [mailto:[EMAIL PROTECTED]]
Sent: 24 September 2002 06:22 AM
To: [EMAIL PROTECTED]
Subject: Properties are causing problem in 1.5
Hello all,
I'm working with nested properties in some custom tasks. The property
ea_survivalVar is supposed to get set and then the the task beta is
supposed to pick up its value. (See below)
These work fine in 1.4.1 but now I get problems when I try to use 1.5.
Now in Ant 1.5 the property ea_survivalVar is not available to the
beta task. Any suggestions would be apprieciated.
target name=error_analysis
batch iterations=5 name=ea
property name=ea_survivalVar value=0.015/
beta name=ea_survivalMean mean=0.98 std=${ea_survivalVar}/
antcall target=pva/
/batch
/target
the batch tag is really simple it is just a TaskContainer that performs
its nested tasks a specific number of times:
public void execute() throws BuildException {
if (name != null) {
if (iterations = 0) {
throw new BuildException(You must specify the number
of iterations ( 0 ),location);
}
}
for(int i = 0 ; i iterations ; i++){
project.setProperty(name, Integer.toString(i));
for (Enumeration e = nestedTasks.elements();
e.hasMoreElements();) {
Task nestedTask = (Task)e.nextElement();
nestedTask.maybeConfigure();
nestedTask.perform();
}
}
}
-Mark
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]] 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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 [EMAIL PROTECTED] To: Ant Users List [EMAIL PROTECTED] 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:[EMAIL PROTECTED]] 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Ant Perversions [was RE: Properties are causing problem in 1.5]
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:[EMAIL PROTECTED]] Sent: Wednesday, May 01, 2002 7:29 PM To: Ant Users List; [EMAIL PROTECTED] 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 [EMAIL PROTECTED] To: Ant Users List [EMAIL PROTECTED] 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
Re: Ant Perversions [was RE: Properties are causing problem in 1.5]
- Original Message - From: Scott Stirling [EMAIL PROTECTED] To: Ant Users List [EMAIL PROTECTED] 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:[EMAIL PROTECTED]] Sent: Wednesday, May 01, 2002 7:29 PM To: Ant Users List; [EMAIL PROTECTED] 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 [EMAIL PROTECTED] To: Ant Users List [EMAIL PROTECTED] 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
RE: Properties are causing problem in 1.5
I had a problem similar to this. What I had to do was make the secondary
task a dependency of the first task in order to inherit the property.
ie:
target name=error_analysis depends=set_attribute
echo message=${ea_survivalVar} /
/target
target name=set_attribute
property name=ea_survivalVar value=x /
/target
d.
-Original Message-
From: Mark R. Diggory [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 25, 2002 3:32 PM
To: [EMAIL PROTECTED]
Subject: Properties are causing problem in 1.5
I didn't get any response from the group so I'm reposting this message:
-Mark
Hello all,
I'm working with nested properties in some custom tasks. The property
ea_survivalVar is supposed to get set and then the the task beta is
supposed to pick up its value. (See below)
These work fine in 1.4.1 but now I get problems when I try to use 1.5.
Now in Ant 1.5 the property ea_survivalVar is not available to the
beta task. Any suggestions would be apprieciated.
target name=error_analysis
batch iterations=5 name=ea
property name=ea_survivalVar value=0.015/
beta name=ea_survivalMean mean=0.98 std=${ea_survivalVar}/
antcall target=pva/
/batch
/target
the batch tag is really simple it is just a TaskContainer that performs
its nested tasks a specific number of times:
public void execute() throws BuildException {
if (name != null) {
if (iterations = 0) {
throw new BuildException(You must specify the number
of iterations ( 0 ),location);
}
}
for(int i = 0 ; i iterations ; i++){
project.setProperty(name, Integer.toString(i));
for (Enumeration e = nestedTasks.elements();
e.hasMoreElements();) {
Task nestedTask = (Task)e.nextElement();
nestedTask.maybeConfigure();
nestedTask.perform();
}
}
}
-Mark
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Properties are causing problem in 1.5
Here's my error.
Buildfile: build.xml
error_analysis:
BUILD FAILED
file:C:/cagn/WEB-INF/examples/BatchExample/build.xml:23:
java.lang.NumberFormatE
xception: ${ea_survivalVar}
I tried adding dependencies, but it didn't help, plus the property is
currently set in the same target as it is used, it seems it should be
available.
-Mark
David McTavish wrote:
I had a problem similar to this. What I had to do was make the secondary
task a dependency of the first task in order to inherit the property.
ie:
target name=error_analysis depends=set_attribute
echo message=${ea_survivalVar} /
/target
target name=set_attribute
property name=ea_survivalVar value=x /
/target
d.
-Original Message-
From: Mark R. Diggory [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 25, 2002 3:32 PM
To: [EMAIL PROTECTED]
Subject: Properties are causing problem in 1.5
I didn't get any response from the group so I'm reposting this message:
-Mark
Hello all,
I'm working with nested properties in some custom tasks. The property
ea_survivalVar is supposed to get set and then the the task beta is
supposed to pick up its value. (See below)
These work fine in 1.4.1 but now I get problems when I try to use 1.5.
Now in Ant 1.5 the property ea_survivalVar is not available to the
beta task. Any suggestions would be apprieciated.
target name=error_analysis
batch iterations=5 name=ea
property name=ea_survivalVar value=0.015/
beta name=ea_survivalMean mean=0.98 std=${ea_survivalVar}/
antcall target=pva/
/batch
/target
the batch tag is really simple it is just a TaskContainer that performs
its nested tasks a specific number of times:
public void execute() throws BuildException {
if (name != null) {
if (iterations = 0) {
throw new BuildException(You must specify the number
of iterations ( 0 ),location);
}
}
for(int i = 0 ; i iterations ; i++){
project.setProperty(name, Integer.toString(i));
for (Enumeration e = nestedTasks.elements();
e.hasMoreElements();) {
Task nestedTask = (Task)e.nextElement();
nestedTask.maybeConfigure();
nestedTask.perform();
}
}
}
-Mark
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Properties are causing problem in 1.5
This looks like the same problem I had when designing foreach2
See http://www.geoff-meakin.com/antattack.html
Basically you have the trouble because the first time a Task
is performed, it maybeConfigures its environment (see
RuntimeConfigurable and ProjectHelper.configure) which overrides
the values of your XMLattributes with the correct property
substitutions. Now because thats already been done, if you try
and do it a second time with the same Task, the properties dont
get reset.
I had to override the RuntimeConfigurable in ANTCore to get this
working. If it helps, look at the sourcecode which I provide on
the website which fixes this problem. If it helps use the
foreach2 task jar, because it does what I believe you're trying
to do anyway.
See what you think
Cheers
-Geoff
-Original Message-
From: Mark R. Diggory [mailto:[EMAIL PROTECTED]]
Sent: 24 September 2002 06:22 AM
To: [EMAIL PROTECTED]
Subject: Properties are causing problem in 1.5
Hello all,
I'm working with nested properties in some custom tasks. The property
ea_survivalVar is supposed to get set and then the the task beta is
supposed to pick up its value. (See below)
These work fine in 1.4.1 but now I get problems when I try to use 1.5.
Now in Ant 1.5 the property ea_survivalVar is not available to the
beta task. Any suggestions would be apprieciated.
target name=error_analysis
batch iterations=5 name=ea
property name=ea_survivalVar value=0.015/
beta name=ea_survivalMean mean=0.98 std=${ea_survivalVar}/
antcall target=pva/
/batch
/target
the batch tag is really simple it is just a TaskContainer that performs
its nested tasks a specific number of times:
public void execute() throws BuildException {
if (name != null) {
if (iterations = 0) {
throw new BuildException(You must specify the number
of iterations ( 0 ),location);
}
}
for(int i = 0 ; i iterations ; i++){
project.setProperty(name, Integer.toString(i));
for (Enumeration e = nestedTasks.elements();
e.hasMoreElements();) {
Task nestedTask = (Task)e.nextElement();
nestedTask.maybeConfigure();
nestedTask.perform();
}
}
}
-Mark
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
