Discussions

News: Ant 1.7.0 Released

  1. Ant 1.7.0 Released (40 messages)

    Apache Ant 1.7.0 is now available for download. Ant 1.7 introduces a resource framework. Resources are abstractions of "file-like entities," which might be files, but can also be zip entries, tar entries, paths, etc., and some of the core ant tasks such as are now able to process resources in addition to files. Resource collections group resources, and can be further combined with operators such as union and intersection. This can be extended by custom resources and custom tasks using resources. There is also a new concept of selectors, which provide additional filters for fileset members to control whether a file is appropriate for a task. The constraints include a simple grep ("include if the text is contained in the file"), date modifications selectors ("select if modified after or before..."), distance in a directory tree, file size, and others. Ant 1.7 starts outsourcing of optional tasks to Antlibs. The .NET antlib in preparation will replace the .NET optional tasks which ship in Ant. Support for the version control system Subversion will be only provided as an antlib to be released shortly. Ant 1.7 fixes also a large number of bugs.

    Threaded Messages (40)

  2. Re: Ant 1.7.0 Released[ Go to top ]

    Nice, but what we actually need is: - control-flow support (if-else-elsif-endif, foreach, choose-when), - exception handling support (try-catch-finally) - better variables, expressions and functions support in order to build moderately and highly complex systems and to support high-level of automation (not just building, but deploying, testing, reporting...).
  3. Re: Ant 1.7.0 Released[ Go to top ]

    Nice, but what we actually need is:
    - control-flow support (if-else-elsif-endif, foreach, choose-when),
    - exception handling support (try-catch-finally)
    - better variables, expressions and functions support
    in order to build moderately and highly complex systems and to support high-level of automation (not just building, but deploying, testing, reporting...).
    +1
  4. Re: Ant 1.7.0 Released[ Go to top ]

    Nice, but what we actually need is:
    - control-flow support (if-else-elsif-endif, foreach, choose-when),
    - exception handling support (try-catch-finally)
    - better variables, expressions and functions support
    in order to build moderately and highly complex systems and to support high-level of automation (not just building, but deploying, testing, reporting...).
    -1 Deploying, testing and reporting are possible right now. There are enough scripting languages to do other "high level" stuff. "Apache Ant is a Java-based build tool" and is already complex enough.
  5. Re: Ant 1.7.0 Released[ Go to top ]

    Nice, but what we actually need is:
    - control-flow support (if-else-elsif-endif, foreach, choose-when),
    - exception handling support (try-catch-finally)
    - better variables, expressions and functions support
    in order to build moderately and highly complex systems and to support high-level of automation (not just building, but deploying, testing, reporting...).


    -1

    Deploying, testing and reporting are possible right now.
    There are enough scripting languages to do other "high level" stuff. "Apache Ant is a Java-based build tool" and is already complex enough.
    It is possible, but: - I need to deploy different things to different environments (condition) - I need to deploy the same component multiple times to the same environment but with different configuration parameters (looping with condition inside) - I need perform different tasks when deploying for the first time then when upgrading the environment (condition) - I need to do clean-up when build fails (exception handling) - I need to check if my system is up or not (functions & condition) - I need to repeat my performance test with different input parameters (looping) It sure can be handled with existing Ant, but it ends up pretty ugly (leveraging targets with if/unless and custom Ant tasks).
  6. Re: Ant 1.7.0 Released[ Go to top ]

    - I need to check if my system is up or not (functions & condition)
    - I need to repeat my performance test with different input parameters (looping)

    It sure can be handled with existing Ant, but it ends up pretty ugly (leveraging targets with if/unless and custom Ant tasks).
    I think checking to see if a server is up is well beyond the best practices of ANT usage. It really sounds like you're trying to hammer that square peg into that round hole. The benefit of ANT is that they kept the API relatively simple so novice developers wouldn't be confused by the options and attempt to do complex conditional logic. It's designed to build applications. It's not designed to restart your server if it crashes.
    - I need perform different tasks when deploying for the first time then when upgrading the environment (condition)
    Most of us redeploy apps many, many, many times more than initial deployments. Perhaps two build scripts will accomplish what you need more than one. Our redeployment releases are run several times a week. Our initial deployments occur once every 2 years or more. I don't want to pollute my build script that gets run weekly with a bunch of logic which rarely ever gets run. I don't see what you're accomplishing here by consolidating so much. Certainly, you can easily accomplish this with 2 targets or scripts. Also, I have no idea what enterprise Java processes this describes. I have seen this scenario for database deployment, but not WAR/EAR deployment. I'd argue that ANT is not the tool you want for SQL deployment anyway, but that's more of a personal taste issue than a best practice. If this is a standalone application, you may need a conventional installer tool and not ANT. ANT is optimized for local builds and enterprise packaging. It also handles enterprise deployment well. It is not, however, an installer application, like InstallAnywhere.
  7. Re: Ant 1.7.0 Released[ Go to top ]

    - I need to check if my system is up or not (functions & condition)
    I think checking to see if a server is up is well beyond the best practices of ANT usage. It really sounds like you're trying to hammer that square peg into that round hole.
    Not at all! Checking if a server is up IS a common practice in build (or more general, process automation) scripts. Ant is only a tool, and its best practices has to adopt to what is commonly needed and not the other way round.
    The benefit of ANT is that they kept the API relatively simple so novice developers wouldn't be confused by the options and attempt to do complex conditional logic. It's designed to build applications. It's not designed to restart your server if it crashes.
    That is it's main problem, it is designed for novice developers, but then macros, includes and other stuff is added, which is not simple for novice developers, neither powerful enough to enable automation of medium and high complex systems. Btw. in build scripts, you do not try to restart server if it crashes, but to shut it down before cold-upgrade ;)
  8. Ant is not a deployment tool[ Go to top ]

    I am part of the Ant team; I really work full time on deployment of complex applications. Ant is a build tool, not a deployment tool. Builds are about : compile, package, test. Deployment is "bring up mysql, wait at most 5 minutes for the db to become visible then start the app server". The deployment configuration can include links to check system health, something the runtime can check. The runtime can also undeploy at shutdown. Ant tasks have a limited lifecycle "Execute". they know nothing about checking the health of deployed things, they know nothing about undeployment. With ant-contrib you can hack some of this stuff up, but you will be permanently unsatisfied because the runtime itself is a build tool, not a deployment tool -steve
  9. Re: Ant 1.7.0 Released[ Go to top ]

    -1

    Deploying, testing and reporting are possible right now.
    There are enough scripting languages to do other "high level" stuff. "Apache Ant is a Java-based build tool" and is already complex enough.
    Just because something is complex enough doesn't mean it's rich enough (think about it: we're back to #include!) I certainly think that ant needs some of the features mentioned by the original poster, and then some: - Better expressions (if/else/while). - Better variables - Inheritance of tasks or entire files. Very often, I want to reuse an existing task and simple add a task or change a parameter. macrodef and include help somewhat, but you still end up with a lot of redundancy and increasingly fragile build files As for Maven, I have to say I am still trying to wrap my head around the following paradox: - It seems to enjoy a reasonable market share. - It looks like upgrading libraries to newer versions causes all kinds of havocs on users and developers alike, and hardly anyone (even in the Maven team) seems to have a holistic view of the entire system, resulting in endless finger pointing and bug reports being bounced back and forth. -- Cedric http://testng.org
  10. to address Cedric's concerns[ Go to top ]

    Just because something is complex enough doesn't mean it's rich enough (think about it: we're back to #include!)

    I certainly think that ant needs some of the features mentioned by the original poster, and then some:

    - Better expressions (if/else/while).
    ant-contrib's if and for tasks go a long way here.
    - Better variables
    How do you mean?
    - Inheritance of tasks or entire files. Very often, I want to reuse an existing task and simple add a task or change a parameter. macrodef and include help somewhat, but you still end up with a lot of redundancy and increasingly fragile build files
    I assume you mean when you say "include" (No problem, just checking)... wrt "inheritance of tasks," might be a better fit here than . That said, is extremely useful as well IMHO. I'm afraid I can't answer your allegations of redundancy and fragility without more information, however.   :|
    As for Maven, I have to say I am still trying to wrap my head around the following paradox:
    - It seems to enjoy a reasonable market share.
    - It looks like upgrading libraries to newer versions causes all kinds of havocs on users and developers alike, and hardly anyone (even in the Maven team) seems to have a holistic view of the entire system, resulting in endless finger pointing and bug reports being bounced back and forth.
    ;) -Matt (ant.apache.org)
  11. Re: to address Cedric's concerns[ Go to top ]

    Better expressions (if/else/while).

    ant-contrib's if and for tasks go a long way here.

    XML is not naturally fitted to do this in an elegant way. Yes, it's OK, but can't be combined with other scripting powers. It hurts me in every way each time I look at a build script with ant contrib expressions like if/else, etc... Ilya
  12. Re: Ant 1.7.0 Released[ Go to top ]

    Personally, i like the lack of explicit branching past antcall. It means tasks are responsible for their running via the unless attribute. As for looping, isn't that up to the task to operate on a set of items and loop as needed? For testing and deploying, can you elaborate? People have written tasks for them. Maybe they weren't sufficient?
  13. Re: Ant 1.7.0 Released[ Go to top ]

    Nice, but what we actually need is:
    - control-flow support (if-else-elsif-endif, foreach, choose-when),
    - exception handling support (try-catch-finally)
    - better variables, expressions and functions support
    in order to build moderately and highly complex systems and to support high-level of automation (not just building, but deploying, testing, reporting...).
    No, please don't. There are third party tasks that do that and it gets ugly very quickly. What's needed is something to supporting the embedding of scripting within Ant's runtime, though allowing to facilitate such a request. You can see the thread on the Raven post earlier. Also, maybe even embedding of velocity templates within the build file, would accomplish this more elegantly. Ilya
  14. Re: Ant 1.7.0 Released[ Go to top ]

    Nice, but what we actually need is:
    - control-flow support (if-else-elsif-endif, foreach, choose-when),
    - exception handling support (try-catch-finally)
    - better variables, expressions and functions support
    in order to build moderately and highly complex systems and to support high-level of automation (not just building, but deploying, testing, reporting...).


    No, please don't. There are third party tasks that do that and it gets ugly very quickly. What's needed is something to supporting the embedding of scripting within Ant's runtime, though allowing to facilitate such a request. You can see the thread on the Raven post earlier.

    Also, maybe even embedding of velocity templates within the build file, would accomplish this more elegantly.

    Ilya
    It maybe so, it may not. For example NAnt does have support for all this (although not that perfect) and it comes pretty handy. And it does not mess up the things (at least in my experience) as control flow that is needed in build scripts is rather simple (but not that simple enough to be covered by modest Ant support). Btw. most of things can be abused, but currently Ant targets/if/unless must be abused to support some sort of flow control that is actually needed. And it ends pretty ugly, sure uglier then potential if-elsif-else tags. So I would prefer if-elsif-else/choose-when/try-catch-finally/foreach tags as well as better support for variables, expressions & functions (maybe this would be the best point for introducing a dynamic scripting language to Ant).
  15. Scripting in Ant[ Go to top ]

    What's needed is something to supporting the embedding of scripting within Ant's runtime, though allowing to facilitate such a request.
    This is completely supported in Ant through the use of the <script> and <scriptdef> tasks. The <script> task allows you to execute a script written in any scripting language supported by the Bean Scripting Framework (BSF) inside of an Ant target. See http://jakarta.apache.org/bsf/ for a list of the languages supported. Documentation on using the <script> task is here: http://ant.apache.org/manual/OptionalTasks/script.html The <scriptdef> task allows you to define a new Ant task by writing it in any of the BSF-supported languages. Documentation on the <scriptdef> task is available at http://ant.apache.org/manual/OptionalTasks/scriptdef.html. These tasks expose much of the Ant API to the scripting environments, too, so if your project is named "MyProject", then you can write a script task in your build.xml like: <blockquote><script language="javascript"> <![CDATA[ for (i=1; i<=10; i++) { echo = MyProject.createTask("echo"); echo.setMessage(i*i); echo.perform(); } ]]> </script>
  16. Declarative vs. Procedural[ Go to top ]

    Nice, but what we actually need is:
    - control-flow support (if-else-elsif-endif, foreach, choose-when),
    - exception handling support (try-catch-finally)
    - better variables, expressions and functions support
    in order to build moderately and highly complex systems and to support high-level of automation (not just building, but deploying, testing, reporting...).
    Ant is designed to be a declarative system. The Ant developers believed very strongly that a build system should be declarative rather than procedural. The difference between the two is quite fundamental. In a declarative language, you define the relationships between things. If you've ever used Prolog, you know what this looks like. Specifically in Ant, you define the dependencies between targets. Then you let Ant figure out what needs to be done in order to meet the dependencies. This is very different from procedural programming, where instead of letting the system figure out what needs to be done, you specifically tell it what to do step-by-step. Unfortunately, most people don't have any experience with declarative languages. They don't know how to use them. What they know is procedural languages, and thus they find using Ant frustrating because it doesn't match up with their view of how you get things done on a computer. So the Ant community has come up with a compromise. Best practice is to use the declarative approach and that is what we provide out of the box, but if you really want to go procedural then you can download the ant-contrib tasks and use them. It requires a little bit of extra effort on your part because it is not the best way to go, but the choice is still ultimately yours.
  17. Re: Declarative vs. Procedural[ Go to top ]

    Ant is designed to be a declarative system. The Ant developers believed very strongly that a build system should be declarative rather than procedural.

    The difference between the two is quite fundamental. In a declarative language, you define the relationships between things. If you've ever used Prolog, you know what this looks like. Specifically in Ant, you define the dependencies between targets. Then you let Ant figure out what needs to be done in order to meet the dependencies. This is very different from procedural programming, where instead of letting the system figure out what needs to be done, you specifically tell it what to do step-by-step.

    Unfortunately, most people don't have any experience with declarative languages.
    If you want to call ant a language, than the use of XML was a poor choice. I don't see it as a language, rather a description of the build process. There shouldn't be any language level constructs and idioms in the buid descriptions.
    They don't know how to use them. What they know is procedural languages, and thus they find using Ant frustrating because it doesn't match up with their view of how you get things done on a computer.
    I'd argue that most people here are familiar with OO and proceedural:-) This is a java community.
    So the Ant community has come up with a compromise. Best practice is to use the declarative approach and that is what we provide out of the box, but if you really want to go procedural then you can download the ant-contrib tasks and use them. It requires a little bit of extra effort on your part because it is not the best way to go, but the choice is still ultimately yours.
    No, xml is horrible when it comes to any programming, though we need to reach a compromise. The build process should be a combination of declarative and dynamic scripting support. ant-contrib at time allows you to accomplish some simple logical contstructs, but they look very ugly and bring xml to the forefront of what it should never be used for and that's DSL. Ilya
  18. XML for scripting[ Go to top ]

    If you want to call ant a language, than the use of XML was a poor choice. I don't see it as a language, rather a description of the build process. There shouldn't be any language level constructs and idioms in the build descriptions.
    I agree with you. So do other Ant developers (see http://stefan.samaflost.de/blog/en/Apache/Ant/would_ant_be_different_without_xml.html for example). James Duncan Davidson, the original developer of Ant, would always say "Ant is not a language." Then he watched as people extended it to be a language. Last year, he said that if he had any idea people would work so hard to turn Ant into a scripting language, he never would have adopted XML as the file format.
    I'd argue that most people here are familiar with OO and proceedural:-)
    Object oriented code is orthogonal to this. Apparently, there are object oriented declarative languages around (http://oopl.sourceforge.net/ or http://www.lpa.co.uk/ppp.htm for example).
  19. Ant and Control flows[ Go to top ]

    As the original author of the ant-contrib library, I can see how things like , and can litter your code. However, there are times when they really are needed to meet the requirements of the build/deployment process. Take the task, it's helpful in a deployment process to specify the boxes you want to deploy on in a properties file: deploy.hosts=host1,host2 and in your script, execute a macro for each host: Compare that to what it takes to do this with a script: <script language="javascript"><![CDATA[ String hosts = getProject.getProperty("deploy.hosts"); StringTokenizer st = new StringTokenizer(hosts, ","); while (st.hasMoreTokens()) { String host = st.nextToken(); DoSomething t = (DoSomething) getProject().createTask("do-something"); t.setHost(host); t.perform(); } ]]></script> Not only is this more verbose, but it requires that you install the scripting language jar in your core ant installation. If you don't the and tags will not be able to find the scripting language classes. This means you can't just give someone a zip file with your script and the supporting custom tasks, you have to alter your ant installation. With antcontrib, you can load the .jar with a and run without altering your ant distribution. I won't get into the philosophical discussion of control flow in ANT (I understand why the ANT authors don't want to include it), I'm just trying to point out how much cleaner it is to use tasks for this, rather than scripting languages. (I still haven't figured out why is acceptable, but not , since is just a special case of ). That being said I do try to stick with core ant as much as I can. There are just times when it simply cannot provide me with the requirements that I am presented with for the build. I would have liked to have seen more things moved out to antlibs with the 1.7 release, but the mere release of the AntUnit antlib will help tremendously (I've found using BuildFileTest doesn't always give reliable results, due to certain classloader issues).
  20. Re: Ant and Control flows[ Go to top ]

    I won't get into the philosophical discussion of control flow in ANT (I understand why the ANT authors don't want to include it)
    This discussion should not be philosophical but pragmatical ;). Simply there are too many use cases where declarative approach does not fit.
    I'm just trying to point out how much cleaner it is to use tasks for this, rather than scripting languages.
    +1
    That being said I do try to stick with core ant as much as I can.
    Right. And this should just be well documented and promoted (the use of declarative approach over procedural, when it's feasible) and there should not be much abuse.
  21. Re: Ant and Control flows[ Go to top ]

    For me Ant= Java + Complicated Property file. Why do I need try/catch in supposedly simple build tool? If I need something like that I would better call execute java or my own task from the Ant for some logical processing. Just because you can see logic in XML doesn't justify making ANT more of programming language that too based on XML (worst!!).
  22. Re: Ant and Control flows[ Go to top ]

    Hi Matthew,
    As the original author of the ant-contrib library, I can see how things like , and can litter your code. However, there are times when they really are needed
    to meet the requirements of the build/deployment process.
    Take the task, it's helpful in a deployment process
    to specify the boxes you want to deploy on in a properties
    file:

    deploy.hosts=host1,host2

    and in your script, execute a macro for each host:







    Compare that to what it takes to do this with a script:

    <script language="javascript"><![CDATA[<br> String hosts = getProject.getProperty("deploy.hosts");<br> StringTokenizer st = new StringTokenizer(hosts, ",");<br> while (st.hasMoreTokens()) {<br> String host = st.nextToken();<br> DoSomething t = (DoSomething) getProject().createTask("do-something");<br> t.setHost(host);<br> t.perform();<br> }<br> ]]></script>

    Not only is this more verbose, but it requires that you install the scripting language jar in your core ant installation.
    That's a very interesting example, and in my opinion, it proves the opposite of what you are tring to show :-) The script approach might be more verbose, but it's also more understandable than the hybrid XML version: it has much less noise and it's written in a way that programmers understand, since it's their language as opposed to ant-contrib's version of what it thinks they need. And let's make your example more interesting: what if these host names come from a text file? An Excel spreadsheet? A database? Do you see why the only acceptable extensibility is by embedding an interpreter? And by the way, please don't see that as a rebuke to your work, I certainly appreciate your efforts to make our lives with ant easier. I just hope you will slightly refocus your efforts toward what I think is a better solution :-) -- Cedric http://testng.org
  23. Control Flows[ Go to top ]

    I guess we'll just agree to disagree. I find the task oriented syntax much simpler and clearer than the script based syntax. Especially when the tasks to be executed is a bit more complex, and when you start dealing with things other than string based lists to iterate (filesets, paths, etc...).
  24. Re: Declarative vs. Procedural[ Go to top ]

    Ant is designed to be a declarative system. The Ant developers believed very strongly that a build system should be declarative rather than procedural.

    The difference between the two is quite fundamental. In a declarative language, you define the relationships between things. If you've ever used Prolog, you know what this looks like. Specifically in Ant, you define the dependencies between targets. Then you let Ant figure out what needs to be done in order to meet the dependencies. This is very different from procedural programming, where instead of letting the system figure out what needs to be done, you specifically tell it what to do step-by-step.

    Unfortunately, most people don't have any experience with declarative languages. They don't know how to use them. What they know is procedural languages, and thus they find using Ant frustrating because it doesn't match up with their view of how you get things done on a computer.

    So the Ant community has come up with a compromise. Best practice is to use the declarative approach and that is what we provide out of the box, but if you really want to go procedural then you can download the ant-contrib tasks and use them. It requires a little bit of extra effort on your part because it is not the best way to go, but the choice is still ultimately yours.
    It is OK for Ant to be declarative at high level (tasks, targets, ...) , but you really need some procedural spice to do the job at hand. Did you read the use-cases of procedural stuff in my previous posts? They are all very common, needed by most people, nothing special. So if I have a set of environments and I have a system with a set of components and I need to deploy different sub-sets of components to different environment, how do I do this in declarative way using current Ant constructs? And this is common problem, most systems are deployed to several environments and and are composed of several components, aren't they?
  25. Re: Declarative vs. Procedural[ Go to top ]

    The Ant developers believed very strongly that a build system should be declarative rather than procedural.

    The difference between the two is quite fundamental. In a declarative language, you define the relationships between things. If you've ever used Prolog, you know what this looks like. Specifically in Ant, you define the dependencies between targets. Then you let Ant figure out what needs to be done in order to meet the dependencies. This is very different from procedural programming, where instead of letting the system figure out what needs to be done, you specifically tell it what to do step-by-step.

    Unfortunately, most people don't have any experience with declarative languages. They don't know how to use them. What they know is procedural languages, and thus they find using Ant frustrating because it doesn't match up with their view of how you get things done on a computer.

    So the Ant community has come up with a compromise. Best practice is to use the declarative approach and that is what we provide out of the box, but if you really want to go procedural then you can download the ant-contrib tasks and use them. It requires a little bit of extra effort on your part because it is not the best way to go, but the choice is still ultimately yours.
    While I agree that a build system needs to be based on a declarative style, because that's what most of the build tasks will be, it also needs to support some sort of procedural language, and that's why the Prolog metaphor doesn't apply here. The only way you can do this with ant is to drop down at the Java level and write your own tasks. This is definitely a good solution, and it accounts for a great part for ant's success, but it also introduces some bad schizophreny in build systems (how do I decide if I should write a macro or write a Java task?), and it also comes at a price in terms of configuration (need to set the classpath and declare the task, which can be done in several ways). I think the ideal solution is a build description system that lets me mix both: mostly declarative in style, but where I can insert lines of code whenever I need, without having to compile, jar or configure anything. Rake and Grant have made some interesting steps in this direction, and I hope they keep investigating this hybrid approach. -- Cedric http://testng.org
  26. to Cedric, RE procedural band-aids[ Go to top ]

    While I agree that a build system needs to be based on a declarative style, because that's what most of the build tasks will be, it also needs to support some sort of procedural language, and that's why the Prolog metaphor doesn't apply here.

    The only way you can do this with ant is to drop down at the Java level and write your own tasks. This is definitely a good solution, and it accounts for a great part for ant's success, but it also introduces some bad schizophreny in build systems (how do I decide if I should write a macro or write a Java task?), and it also comes at a price in terms of configuration (need to set the classpath and declare the task, which can be done in several ways).

    I think the ideal solution is a build description system that lets me mix both: mostly declarative in style, but where I can insert lines of code whenever I need, without having to compile, jar or configure anything. Rake and Grant have made some interesting steps in this direction, and I hope they keep investigating this hybrid approach.

    --
    Cedric
    http://testng.org
    "the only way" is to write a task? Don't forget that you do have multiple scripting options available as well. The cost of <script> has just gone down tremendously with the advent of Java 6; you can use its built-in javascript support to have ad-hoc scripting with (AFAIU) no configuration tradeoffs other than Java 6 itself. -Matt (ant.apache.org)</script>
  27. Re: Ant 1.7.0 Released[ Go to top ]

    Nice, but what we actually need is:
    - control-flow support (if-else-elsif-endif, foreach, choose-when),
    - exception handling support (try-catch-finally)
    - better variables, expressions and functions support
    in order to build moderately and highly complex systems and to support high-level of automation (not just building, but deploying, testing, reporting...).
    +1 Plus OO like inheritance; only the , not the env though.
  28. Nice, but what we actually need is:
    - control-flow support (if-else-elsif-endif, foreach, choose-when),
    - exception handling support (try-catch-finally)
    - better variables, expressions and functions support
    in order to build moderately and highly complex systems and to support high-level of automation (not just building, but deploying, testing, reporting...).
    If you need these features when building your application, I'd say it's time to rethink the architecture of your application. Through use of JDNI, I've completely eliminated the need to repackage wars for different servers on every project I've ever worked on. I have a project where I literally deploy to 30 different servers, representing 4 different environments. A single war can be deployed to every server. That keeps the build script very simple. Regarding deployment, I deploy to different servers using different scripts or ANT targets, the only variation being the Tomcat Manager URL. Testing & Reporting? I'm not sure what you're trying to accomplish that you need try/catch and flow control, but running JUnit tests couldn't be simpler. I don't yet see the need for complex logic. First of all, I'd recommend that you get more familiar with your container. It probably has the answers to all of your problems. Look into JNDI datasources and environment variables. Secondly, I'd consider your statement. ANT is a mature and very popular tool. When you find a missing feature, maybe you should stop and think for a minute. Is this feature missing because of the deficiency of the ANT development team or am I trying to do something ANT shouldn't be doing? If your needs are that specialized, you can easily write your own ANT target and get full use of the JAVA API. I've done that before, but found that in the end, I was doing something in ANT that it wasn't designed for and that my overall strategy was flawed. Finally, I recently switched to maven2, and am not going back. Maven2 has saved a lot of time for me and made my application easier to build, made it quick and easy to add new external libraries and components, and made the app less likely to break during active development(less worry of dependencies). Why write cool ANT scripts when, with proper application planning, maven can accomplish all I need out of the box?
  29. I think I agree with most of what you said. Once you move outside of building and packaging ant becomes less appropriate. Now that I've been on a very active Maven 2 project I can see the benefits, but I'm not 100% yet. We've got most of the kinks out of plugging it into Eclipse to please the development team but the marriage isn't perfect. In some ways this is more eclipse's fault since it can't understand a project hierarchy. I think Maven would get a lot more usage if the integration with the top IDEs was more seamless. I think many would be surprised at how hard it is to convince some development teams that having a build that can be run outside of an IDE is a good thing. If there was a more seamless integration between ant and Eclipse or Maven and Eclipse then I wouldn't have to fight that battle at all. The current integrations are fine, but aren't great.
  30. Re: Ant 1.7.0 Released[ Go to top ]

    Nice, but what we actually need is:
    - control-flow support (if-else-elsif-endif, foreach, choose-when),
    - exception handling support (try-catch-finally)
    - better variables, expressions and functions support
    in order to build moderately and highly complex systems and to support high-level of automation (not just building, but deploying, testing, reporting...).
    Has anyone tried Gant?
  31. Re: Ant 1.7.0 Released[ Go to top ]

    Guess control flows are available in ant-contrib..
  32. Re: Ant 1.7.0 Released[ Go to top ]

    Do people still use Ant? I thought Maven 2 was the build tool?
  33. Re: Ant 1.7.0 Released[ Go to top ]

    Do people still use Ant? I thought Maven 2 was the build tool?
    What do you think ? Would they release a new version if it was dead ??
  34. Re: Ant 1.7.0 Released[ Go to top ]

    Do people still use Ant? I thought Maven 2 was the build tool?


    What do you think ? Would they release a new version if it was dead ??
    To be honest I think Ant is on a downward path... I haven't used it for over a year, and everyone I know is moving to Maven 2.
  35. process oriented language[ Go to top ]

    To be honest I think Ant is on a downward path... I haven't used it for over a year, and everyone I know is moving to Maven 2.
    The reason is the ant is often limited and complicated for many situations. Anyway introducing Ant was big step forward for whole Java community.
    And the main reason of this success because Ant is XML based script! But now I would prefer to use some kind of process oriented language. This language must be XML based and have strong functional orientation.
    More Lisp and XSLT like than Prolog. BPEL is example of this kind of language but personally I believe the syntax of it far from perfect :)
  36. Re: Ant 1.7.0 Released[ Go to top ]

    Do people still use Ant? I thought Maven 2 was the build tool?


    What do you think ? Would they release a new version if it was dead ??


    To be honest I think Ant is on a downward path... I haven't used it for over a year, and everyone I know is moving to Maven 2.
    Ant is not on any downward path until a viable alternative comes. And even then, I'm more for extending/refactoring ant vs. starting from scratch. Maven is awesome, I love it, but mostly for standard java projects that can follow a standard project structure/lifecycle that maven supports with it's core and plugins. Yes, you can extend it, but it's still not as flexible as ant is. Therefore, I think the combination of ant and maven 2 is an awesome step towards what will eventually become the next generation build system, with transitive dependency support, declarative convention based configuration, and easy extensibility through a build in scripting mechanism. Ilya
  37. Re: Ant 1.7.0 Released[ Go to top ]

    Do people still use Ant? I thought Maven 2 was the build tool?
    I passed from Ant1.6 to Maven2 for a couple of projects, and it was a nightmare! Thus, I came back to Ant1.6! Now, I saw that there is another tool for ant that makes the same work of Maven2 but more simple: it is Ivy. See the following blog: http://blog.exis.com/colin/archives/2005/03/10/ivy-is-everything-maven-should-havecould-have-been-25-years-ago/ Ivy site: http://www.jaya.free.fr/ Now it is an Apache Incubator project. Bye.
  38. Kudos to the new release. We use Ant with our new Java framework and it really is a time saver. Thanks! http://www.pervasivedatarush.com
  39. xml sucks for builds[ Go to top ]

    I don't understand how people think xml is appropriate for systems like builds. A scripting language is much easier for this. Ruby's rake is awesome... so much more powerful than Ant because you can mix Ruby with the built in rake tasks.....
  40. XML Syntax[ Go to top ]

    The xml syntax can be somewhat cumbersome, but you have to remember, the authors intended it as a DECLARATIVE oriented build solution. It was not meant to be a scripting language. As a declarative solution, XML works perfectly fine, and makes alot of sense. However, if you want it to be a procedural language, yes XML is a bad choice. The authors of ANT have, in fact, stated this several times. If you want to be procedural, try using groovy (which has built-in support for calling ant tasks), or gant (which extends upon the idea of groovy using the ant tasks).
  41. Rake[ Go to top ]

    I don't understand how people think xml is appropriate for systems like builds. A scripting language is much easier for this. Ruby's rake is awesome... so much more powerful than Ant because you can mix Ruby with the built in rake tasks.....
    One way XML works is that other tools can read it, like all the IDEs. Other languages tend to be better for people (good) but harder for apps. There's no easy choice. Where rake is good is not so much because it isnt XML, but because you have the full functionality of ruby. Because java needs to be compiled, you cannot easily mix the two. Ant does have lots of scripting stuff but it has always been a bit of an afterthought, whereas in ruby its the primary way to implement functionality. -Steve Steve Loughran Ant team author: Ant in Action