Discussions

News: Top 15 Ant Best Practices

  1. Top 15 Ant Best Practices (31 messages)

    ONJava has posted "Top 15 Ant Best Practices," by Eric M. Burke. It summarizes many of the author's observations about how to use (and not use) Ant in the field. Some of them are violated by widely-used IDEs, which might be a good hint to the authors.
    1. Adopt Consistent Style Conventions
    2. Put build.xml in the Project Root Directory
    3. Prefer a Single Buildfile
    4. Provide Good Help
    5. Provide a Clean Target
    6. Manage Dependencies Using Ant
    7. Define and Reuse Paths
    8. Define Proper Target Dependencies
    9. Use Properties for Configurability
    10. Keep the Build Process Self-Contained
    11. Use Version Control
    12. Use Ant as the Least Common Denominator
    13. Use zipfileset
    14. Perform the Clean Build Test
    15. Avoid Platform-Specific Ant Wrappers
    What would you add to this list? What would you disagree with, and why? (Note that there's not a tip to "use Maven" in the fifteen. Is this a good idea?)

    Threaded Messages (31)

  2. Re: Top 15 Ant Best Practices[ Go to top ]

    I tend to split the ant file into several smaller ant files which are imported into the main one.
  3. build across multiple env's[ Go to top ]

    well my question could be out of context... but it's related to build. Do you build only once (say build server) and just push the archived artifact from one env to another i.e to dev to test and test to prod or do you build for each env ? which is better way ?
  4. Re: build across multiple env's[ Go to top ]

    Standard practice would be to push build artifacts from one environment to another. The code is compiled once and installed on every environment in succession. This is particularly important for the transition from acceptation to production. (Acceptance testing must be done on the same deliverables that go to production.) Anything environment-dependent should be in configuration files. Any change made to the code in between environments is risky. Sometimes, you can have different builds for development/test (E.g., with added debugging or special authorization settings). Developer might have a special build + deploy target that immediately runs a local application server. (Replacing class files is faster than building a complete WAR/EAR file.) I hope that answers your question.
  5. Build once, deploy many[ Go to top ]

    I definetly go for a single build, which will be adapted to the environment through configuration. As for actual configuration, too many options exists to mention here. Then again, I'm one of the strange people who believe in structured operational processes (like ITIL) and believe that programmers should not deploy anything to a production environment (not because they are not capable, but because it often leaves too many undocumented changes) As for all the maven stuff, I just don't get it. I recently gave it a good go, but after strugling with too many plugin errors I simply reverted back to Ant. Sure Ant has it's flaws, but it's way more What-You-Code-Is-What-You-Get and the resulting scripts are even shorter than the dozen of pom.xml I ended up with (Eclipse workspace based). And yes, the scripts does generate the usual reports such as JUnit and Cobertura and was IMHO a lot easier to aggregate in Ant than with Maven2.
  6. Re: Top 15 Ant Best Practices[ Go to top ]

    Sounds very similar to what Maven already does. ;)
  7. dated article[ Go to top ]

    why are we commenting on a 2003 article?
  8. Re: dated article[ Go to top ]

    why are we commenting on a 2003 article?
    Because no new "Java luminary" has started extoling RoR lately?
  9. Re: dated article[ Go to top ]

    why are we commenting on a 2003 article?
    can u share where the article is ?
  10. Re: dated article[ Go to top ]

    Good point. I read this ages ago. Not that useful.
  11. Use Maven 2[ Go to top ]

    All the best practices (except the zipfileset) are inherent David
  12. seems pretty random advice[ Go to top ]

    It seems the author was struggling to come up with good advice. At least, he seems to be stating the obvious. 1, 11 seem not ant related. 4, 5, 14, 15 are rather obvious 13 I don't really get. What's so special about a zipfileset? 3 I don't agree with. Non trivial systems break down in non trivial bits and pieces. I find I need several buildfiles and need to violate 2 in order to reuse them. So here's some better advice from someone with extensive experience with ant (i.e. me): 1 don't reinvent the wheel but separate project stuff from project unspecific stuff. Essentially most targets you write are reusable across projects. So put them in a build file in a central place and import rather than copy paste. 2 in your central, reusable build file put targets for compile, javadoc, clean, code checkers and other standard stuff. Make sure the declared dependencies make sense and don't trigger redundant stuff (e.g. executing init 20 times is not going to have any effect). 3 Define paths separate from where they are used. Distinguish between compile and run-time paths. 4 Use the same directory structure for your projects this helps you make your central build file more reusable. 5 Each jar, war, ear file should have its own build file (importing the central one). This allows you to do partial builds, rebuilds using standard targets. 6 Use a separate build file in the root of your project to build the other stuff using antcall. This is also where you do packaging. Most of your project specific stuff will be here. 7 Any relative paths should be relative to basedir (hint this + standard directory structure makes module level build files nothing more than an import declaration). 8 Use ant project name as basis for your filename 9 Don't copy paste but use the various reuse enabling features that ant provides. 10 Stick to the conventions. I.e. have the predictable targets with the predictable names and don't name them differently. 11 Having a target compile_foo is a sign that foo needs its own build file (see 5). 12. All your build files have the name build.xml, no exceptions. And yes that means one build file per directory. 13. Have a sensible default for your default target. (i.e. don't make it do unexpected stuff like deploying/undeploying stuff. 14 Invest time to make your reusable build file really good. You'll be using this a long time, any productivity improvement you can squeeze out of ant pays off here. 15 Keep an eye on performance. Ant builds can easily end up taking ages. and finally: Don't be too dogmatic about any of the above.
  13. Another tip[ Go to top ]

    The real advantage of zipfileset as I see it, is the prefix attribute, which can be handy. I disagree with using ant project name as the basis for file name, though I do think that project name should *always* be set, and should match the name of the key artifact that the build will be generating. I agree with the one "build file per directory", and that file be called build.xml but only if that file is to be used as a build file for a project. I tend to use the following conventions for ant scripts: project-*.xml (war,ear,ejb,etc) for a project template utility that is imported to a build.xml. tools-*.xml (standalone) scripts that perform specific utility functions, that are not necessarily part of the build. For example, we use the Maven2 plugin, and we extended it's functionality slightly. The tools-maven.xml has targets to clean the local repository, store an artifact in the local repository, and store a target in the remote repository. the latter two are interactive, and prompt for values unless the respetcive properties have been set. utils-*.xml (xmlbeans,axis,etc) for macros/targets that perform enhance a project*, tools*, or build.xml script. Adding to the list: 16. Document those properties that might be usefully overridden, there are often more than you might think. One of the easier ways I've found is to place them into a separate properties file, that get's read in by the build. Which has comments for each property. 17. Simply the work of clean. Place *anything* that is generated by the build into a single directory. For example, if the directory is called build, then all compiled java files might go into build/classes. A distribution might go into build/dist. Generated code might go into build/generated, and so on.. All clean has to do is delete the the target directory. It's easy to tell your ide to ignore things under the "build" directory for version control. 18. Prefer macros (in 1.6+) or runtarget (in Antcontrib) to antcall. In order to do what it does, antcall must reparse the build script potentially incurring huge overhead, and slowing things down. Use macros when you want to have a parameterized subroutine within your build. If you want other targets to be triggered by another without using depends, then use runtarget, it's more efficient. I tend to use runtarget (or a variant) when I think that the target I'm calling might be overridden at some point. In our build system, I have a core build file that gets imported into each build.xml file. I have much smaller build files that perform specialized functions that I can also import (or not) to extend the core build file in different ways, depending on what the particular build needs to do. O One of the lynchpins behind this is my own version of the runtarget task, that can be defined to call a target only if the target exists, removing the need to define an "empty" target and waste time invoking it. This same task also has an attribute that allows it to call all named instances of a given target. This allows me to have the core build conditionally call "generate-code". If any of the utility scripts that are imported have a "generate-code" target then they get called in the order in which they were imported, without the base build script having to know which scripts these targets were defined in. Rob
  14. Dependencies[ Go to top ]

    Also Consider taking a look at Ivy or the Maven2 plugin to deal with dependencies. A similar solution could be worked around the get task in ant, but both Ivy and Maven2 handle transitive dependencies. This used to be one of my key gripes with Ant. Admittedly, I had to extend the Maven2 plugin slightly, and make a few very minor modifications to the source in order to make it work the way I wanted, including: - more verbose diagnostic messages for failures - better reporting of the dependency graph - allow project version to be defined in one location - the parent pom. (yes, I know that it can be done now, however forcing you to define the parent pom's version sort of defeats the purpose! The fix forces the plugin to use the relative path to discover the parent pom's version through the filesystem if it isn't defined in the project pom.) In the new year, I may take a look at replacing the maven2 plugin with ivy in the repository utility for our build system, to see if there are any advantages rather than further modifying the maven code.
  15. Re: Another tip[ Go to top ]

    I agree with what others have said here, especially Jilles van Gurp and Rob Seegal. I've got one common script for each type of build artefact - JAR, WAR, EJB JAR, EAR. Each project module just imports the appropriate one, so typically a module's build script is just a one line import, occasionally with a few property overrides for customisation. Also, a common script provides targets for setting up new projects and modules via CLI, including dirs, build files, Ivy dependency management files and IDE project files. I think setting up a new project is as easy as with Maven, but has the benefit that it's tailored to our existing development environment & project structure. I'd add another tip:
    • Use Groovy script from the common Ant scripts to implement more complex functionality.
    This has proven extremely useful when I've needed proper scripting as it is often much easier than using Ant hacks (e.g. 'var' and 'if' tasks in ant-contrib) or writing custom Ant tasks. The integration certainly isn't perfect, but Groovy's AntBuilder allows you to easily call Ant tasks to do the stuff Ant does well. I haven't checked out Gant yet though...
  16. Re: seems pretty random advice[ Go to top ]

    It seems the author was struggling to come up with good advice. At least, he seems to be stating the obvious.

    1, 11 seem not ant related.
    4, 5, 14, 15 are rather obvious
    13 I don't really get. What's so special about a zipfileset?

    3 I don't agree with. Non trivial systems break down in non trivial bits and pieces. I find I need several buildfiles and need to violate 2 in order to reuse them.
    +1
    1 don't reinvent the wheel but separate project stuff from project unspecific stuff. Essentially most targets you write are reusable across projects. So put them in a build file in a central place and import rather than copy paste. 2 in your central, reusable build file put targets for compile, javadoc, clean, code checkers and other standard stuff. Make sure the declared dependencies make sense and don't trigger redundant stuff (e.g. executing init 20 times is not going to have any effect). 3 Define paths separate from where they are used. Distinguish between compile and run-time paths.
    4 Use the same directory structure for your projects this helps you make your central build file more reusable.
    I agree with you on this. I have used in this technique in serveral projects and works really well.
    5 Each jar, war, ear file should have its own build file (importing the central one). This allows you to do partial builds, rebuilds using standard targets.
    I am not sure I agree with you on this advice. Each sub-module or project should have itsown build.xml file. You can use separate targets for each jar,war,ear files. Having each build.xml file for each ear,war, ear seems too much.
    6 Use a separate build file in the root of your project to build the other stuff using antcall. This is also where you do packaging. Most of your project specific stuff will be here.
    I have used the similar approach. I use a separate build.xml file and antcall to consolidate all the sub-project/module build into a one build file, which can be used by automated build server such as LuntBuild or Anthill. The only difference I have done from you is that I have a separate BUILD module/directory, which contains this separate build.xml. I think I could also put it in root directory.
    7 Any relative paths should be relative to basedir (hint this + standard directory structure makes module level build files nothing more than an import declaration).
    +1
    8 Use ant project name as basis for your filename
    I am not 100% agree with this. I don't like to take it as requriement, there are cases you have to take break this rule.

    9 Don't copy paste but use the various reuse enabling features that ant provides. 10 Stick to the conventions. I.e. have the predictable targets with the predictable names and don't name them differently. 11 Having a target compile_foo is a sign that foo needs its own build file (see 5).
    +1
    12. All your build files have the name build.xml, no exceptions. And yes that means one build file per directory.
    I would not make it so strongly. I would say try to use build.xml for every sub-project/module. Refactory if you need to. You can always break this rule if you think the refactory/restructure is too much effort. But I agree with you on the general principal.
    13. Have a sensible default for your default target. (i.e. don't make it do unexpected stuff like deploying/undeploying stuff.
    The common default in Ant build.xml usually are
    a. build b. help
    14 Invest time to make your reusable build file really good. You'll be using this a long time, any productivity improvement you can squeeze out of ant pays off here. 15 Keep an eye on performance. Ant builds can easily end up taking ages. and finally: Don't be too dogmatic about any of the above.
    +1 I also like to add some other tips which I see affect the overall build in development, testing environments. 1. In many cases, we need to use some conditional construct to perform certain tasks. Ant doesn't provide convenient target for these type of work., For example , if I like to express if (a equals b) do the following block if ( a not equals b) do the following block. Ant does have "equals" but it's under Condition target and not convenient to use. One way to do this is simply write equals ant task yourself, which takes no time at all to perform this sort of tasks. so that target becomes: 2. Its non-avoidable that a build needs to specify the following information:
    hostnames, port nubmers, for database, appserver, file locations, email addresses, SMTP server etc, etc. On top of that, we have different operation systems, Windows, Linux and different deployment directories such as: C:\myApp vs. /opt/myApps vs. /apps/MyApps hard-coded these information into the build system will make the build script unportable. Instead of demanding everything have to be the same (which is impossible), one can utilize the build configuration. In our case (used in two different companies in last 6 years and quite successful), we have put the configuration properties into a separate directory ETC which checked in CVS. Under ETC we have ETC/config.properties --- DEFAULT configuration properties ECT//config.propertes -- user specific configuration ECT///config.properties -- user machine specific configuration propertires. we wrote an ant task which load from ETC properties. machine specifici properties will overwrite the user specicific properties, user configuration overwrite default configuration. If user doesn't specify a properties, it will automatically inherited from default configuration. Also the previous defined properties can be referred through ${} notation. With is setup, all commons properties are defined in the default level configuration, developer will only need to create user or/and machine specific configurations for the specific OS, database, appserver or test properties. For develop, build, test and stage, one only needs to change the proper configuration. This is extreamly helpful for team development and test. (You can certainly use XML instead of file structure if you prefer)
  17. Excellent.
  18. Ant Book[ Go to top ]

    The second edition of 'Java Development with Ant' will be published in 2007. Watch this space on the Manning site. It's likely to become "the" Ant Best Practices Reference.
  19. My biggest suggestion on a build system is only related to ant in that the mistake can be seen in ant files. Avoid architectures that have complex packaging and assembling. The main reason for this is that it will stymie your IDE. You want build steps that closely mirror what an IDE can easily do so that all your refactoring, hot code swapping etc. still works. This often first shows up as overly complicated ant script that has to move and assmeble things to build a deployment. Often times these kind of mistakes are put in by non coding architect types who don't realize their complex packaging has drastically reduced developer productivity.
  20. My biggest suggestion on a build system is only related to ant in that the mistake can be seen in ant files.

    Avoid architectures that have complex packaging and assembling. The main reason for this is that it will stymie your IDE. You want build steps that closely mirror what an IDE can easily do so that all your refactoring, hot code swapping etc. still works.

    This often first shows up as overly complicated ant script that has to move and assmeble things to build a deployment. Often times these kind of mistakes are put in by non coding architect types who don't realize their complex packaging has drastically reduced developer productivity.
    Of course with NetBeans you can tell it to do all necessary packaging, etc, as part of all the IDE actions you normally use. The catch is: (1) you have to devote the time to tell it this (via Ant scripts) and (2) your packaging, etc, has to be something that can be done *very* quickly if properly automated. Along these lines, we've had to use zip.exe (and equivalent on UNIX platforms) rather than or to update jars as zip.exe is *many* times faster!
  21. Maven 2 is vastly superior to Ant. I have converted every development project over to Maven and have nothing but rave reviews across the board from all developers. The Ruby-esque convention maven provides is killer. Download projects like Servicemix to see maven on steroids. I can bring new developers online in lightning speed. Best practices are baked in! If you haven't looked at maven since 1.0 I highly recommend it.
  22. Re: Top 15 Ant Best Practices[ Go to top ]

    1. Use Maven 2.0 instead :) Sergiy
  23. Re: Top 15 Ant Best Practices[ Go to top ]

    Maven Convention over Ant configuration Adopt Consistent Style Conventions - First it's real hard to construct a huge pom.xml file, Maven's equivalent to Ant's build.xml. The baked-in workflow means you extend just what you need. In terms of formatting style, Shift-F on a XML file in Eclipse works for me. Put build.xml in the Project Root Directory - Default convention of Maven to have pom.xml in root. Prefer a Single Buildfile - Ditto on convention. Maven does support profiles in maven pom files so one can call the workflow differently or set different config values. Maven modules allow a project to have subprojects where peer dependencies are configured in a parent pom but build order is determined at runtime based on dependency. Provide Good Help - No brainer once again. Convention is self documenting. I would argue Maven 2.0 is doing a better job at documenting. I think the Spring boys have set a standard that other projects need to meet to drive adoption rate. Provide a Clean Target - Holy crap! Just call "mvn clean" and your project's "target" directory is deleted. No build, bin, or gen dirs to fiddle with all by convention. Manage Dependencies Using Ant - And expend lots of effort managing dependencies with Ant. This is so brain-dead simple in maven. The ability to upgrade to the next version of Hibernate without thinking about what its dependencies include. Maven supports local shared repositories on top of the default ibiblio.org/maven2 repository so one can share pre-built components automagically. Think Ant with a Web 2.0 collaborative dependency service. Cool. Define and Reuse Paths - Convention. Snap! Define Proper Target Dependencies - All managed by maven, maven repository, and maven reactor. Reactor determines build order for maven modules at runtime. But! since all of your deployment units (wars, jars) are precompiled in your local, your shared, or the maven ibiblio repository the build is wicked fast. Use Properties for Configurability - Convention rules the day again for properties like ${src.dir}. Maven provides a filter feature when copying resource files to the target directory. Personally, I use JNDI names and Spring property parameters in order to make properties an environment or container responsibility. Keep the Build Process Self-Contained - NOT! Maven repositories are too powerful. Look what self-containment is doing for North Korea. Use Version Control - Baked-in big time. But even better, Maven uses a SNAPSHOT concept so a team can share alpha/beta builds with other members through the maven repository before checking into version control. Once you get the code right Maven can "release" to your version control system. Snazzy. Use Ant as the Least Common Denominator - If a build system has a command line interface, it can be a common denominator in my book. Maven is an easy replacement and works well with most IDEs. Use zipfileset - Convention, conventon, convention. Maven purpose is to build deployment units like ear, wars, jars, etc.. Perform the Clean Build Test - "mvn clean test" Baked-in. Avoid Platform-Specific Ant Wrappers - Again convention rules. Maven has built in tasks such as "clean,compile,test,install,deploy". You can walk up to any maven project and pretty much know what compile will do.
  24. Re: Top 15 Ant Best Practices[ Go to top ]

    So Maven is the king of build systems. But what to do if I do not like Maven's conventions? What happens WHEN the in-baked functionality fails? Then you come back down from your mountain and go back using Ant, swearing never to use Maven again. But maybe Maven 3.0 will fix it.
  25. Re: Top 15 Ant Best Practices[ Go to top ]

    So Maven is the king of build systems.

    But what to do if I do not like Maven's conventions?

    What happens WHEN the in-baked functionality fails?

    Then you come back down from your mountain and go back using Ant, swearing never to use Maven again. But maybe Maven 3.0 will fix it.
    I would say maven is a better build system than Ant. King? World War I did away with most monarchies. If you do not wish to adhere to convention then you are unconventional. Structure follows strategy. Henry Ford invented the modern assembly line by following convention. Walmart forces convention on suppliers. JavaOne is a convention;) If your legacy code structure has no convention then wallow in your own mess. I can get to market faster. Maven does allow you to override convention but you are not having the aha moment then. Baked-in functionality does not fail - just like Ant. How many builds require Ant 1.6.2+. Same concept with Maven. All dependencies pulled from ibiblio should be backed up in your shared corporate repository so you can build years from now. You should be able to reproduce builds with all elements pulled from version control. Maybe you were burned by Maven 1.0. Alas, me too. But 2.0 is out of rehab, has better documentation, and plugins are coming fast and furious. Ant is great stuff. It got me out of make files but Maven now trumps the crap out of Ant. Maybe its not for everyone but I know I can have a webapp running before you finish your build.xml file.
  26. Maven 2.0 is great[ Go to top ]

    Been using maven it's since 1.0 and it's matured a lot and more cools plugins show up all the time. Example pom below http://svn.sourceforge.net/viewvc/edemocrazy/democracy/trunk/pom.xml?revision=113&view=markup Uses qalab for trend reports of pmd, code coverage(cobertura). Also uses the check executions for pmd,cobertura to break the build for certain constraints. Cool way to reduce the amount of technical debt introduced to projects.
  27. Re: Top 15 Ant Best Practices[ Go to top ]

    So Maven is the king of build systems.

    But what to do if I do not like Maven's conventions?

    What happens WHEN the in-baked functionality fails?

    Then you come back down from your mountain and go back using Ant, swearing never to use Maven again. But maybe Maven 3.0 will fix it.


    I would say maven is a better build system than Ant. King? World War I did away with most monarchies.

    If you do not wish to adhere to convention then you are unconventional. Structure follows strategy. Henry Ford invented the modern assembly line by following convention. Walmart forces convention on suppliers. JavaOne is a convention;) If your legacy code structure has no convention then wallow in your own mess. I can get to market faster. Maven does allow you to override convention but you are not having the aha moment then.

    Baked-in functionality does not fail - just like Ant. How many builds require Ant 1.6.2+. Same concept with Maven. All dependencies pulled from ibiblio should be backed up in your shared corporate repository so you can build years from now. You should be able to reproduce builds with all elements pulled from version control.

    Maybe you were burned by Maven 1.0. Alas, me too. But 2.0 is out of rehab, has better documentation, and plugins are coming fast and furious. Ant is great stuff. It got me out of make files but Maven now trumps the crap out of Ant. Maybe its not for everyone but I know I can have a webapp running before you finish your build.xml file.
    Comparing ant and Maven is kind of silly anyway. Ant is a scripting tool, nothing more. The "build system" comes from how you use it - basically you have to invent it. I like Maven 2.0 a lot but we are still trying to figure out how best to integrate it with MyEclipse so that the developers have all their magic IDE goodness and I have my common outside-of-the-container builds. Of course, Maven can call out to custom tasks so if you need custom work it isn't too hard. I think if you simply "don't like" how maven lays out its projects then that is kind of shallow thinking. I'd rather use any existing standard over inventing my own. Saves me from having to document it. More benefit comes from the Maven plug-ins. I get so many good code metric reports for so little work. Yeah, you could do that with ANT but I'd rather code my project than code up yet-another build system.
  28. ant import[ Go to top ]

    is soooooo slow. Dont use it.
  29. Some Other Best Practices[ Go to top ]

    Some will be repeats from other messages, but here is what I've found. - Do not have truly separate buildfiles, but instead break out related/reusable tasks into a common place and include them via import. If you have true separate buildfiles (that can be accessed only via as opposed to being included by import), you lose the ability to share information, keep dependencies handling from working efficiently and have the overhead of having to invoke ant repeatedly. - Have a build.xml in the top level of your project that should be as short as possible, mainly existing for setting properties and paths that describe the flavor of the project. There will likely be a few custom tasks, but in general, things such as compile should be in imported ant stubs. - Have properties which are likely to be modified by a user in a build.properties file at the same level as the project build.xml. Things such as database login can be located here. Keep properties which are specific to the project in build.xml. - Avoid and where possible. They involve a lot of overhead and dependency handling does not work across them. So if you have something like a "prepare" dependency that sets up directories that almost everything calls, you may end up running it multiple times if you use and . - DRY. This is a big part of having the common ant stubs. Another big part is to use features such as to keep you from doing cut and paste everywhere. - Do not use explicit paths in tasks. Define properties for the paths you will be using. Keep them in a centralized place. - Make sure to have a "description" for any target which a user is expected to run. Make sure not to have a "description" for any internal target which you do not want a user running directly. These internal targets do not have to have correct dependencies as long as they are correctly handled by their calling targets. You can use an xml comment to describe what is happening here. - Use explicit uptodate where necessary. You never want to perform an action that you don't need to as it can cause a cascade of actions to take place later in the build. So if you have a task in a target which creates a file based on another file, make sure you only run it if the source file has been modified more recently than the target file. - If you run an ant task twice in a row that is building something (as opposed to performing an action like starting an app server), it shouldn't do anything. For example, running "ant compile" twice should not do anything the second time. Only if things have changed externally should it do something again. So a good test is to run ant tests that are used often from a clean build multiple times to confirm that the first run does everything needed and that the second time does nothing. This can also help catch bugs such as bad package names in java files, which result in a recompile every single time (and the cascading effects that such an action can have). - Make dependencies only for the most specific requirements. So if you have a target to deploy a war, the only dependency is on building that war. Even though there is the implicit dependency of having to compile that java class for that war, let that be handled by the dependencies of the build war target. - If things start getting too complex, write a custom ant task. - Always make sure that an end user target (see above about description vs. not) builds "correctly". It may slow things down to include dependencies that people don't always want or need, but you don't want people to have to remember that if they want something to perform one way, they need to run another task first. --Tim
  30. Ant call vs. macrodef[ Go to top ]

    Several posts have suggested to use macrodef instead antcall. This is also the advice given by anther article when 1.6 (or 1.6.1) was first comeout about 2 years ago. The main argument is that antcall is not as fast as macrodef, as it will go through the whole initiation process. I have used them both in the past. And at one time, I switched all my antcalls to macrodef after reading the article on TSS. I found that beside the performance is minmium (comparing to my 2-3 minutes build time), using macrodef actually makes the build code messey. Macrodef is not a target. So you cann't not individually test the macro. You have to create another target which wrap the macro to test it. One need to define and pass the proper arguments for marco to function. This invovles constant change on the macrodef as the build file evovles. For antcall, everything is a target. You wrote it you test it. no more wrappers. Pretty much you can use any property in the target. If you want the property to be use a different value than previous defined in the target, simply overwrite the property in the antcall. Much cleaner code and easier to maintain. I am no longer use macrodef in my new project. Of course, this is just my experience. yours may differ. Chester
  31. Several posts have suggested to use macrodef instead antcall
    The impact antcall will have depends on the size of your build script, and the number of times it is called within your build. In some of our scripts, the difference can be a lot! I find macrodef makes the most sense when I want to have a parameterized call. Other than that, it is effectively a private target, or more accurately an ant task that has been defined using XML. For cases where you don't intend to pass parameters but simply call the the target, the Antcontrib runtarget is the way to go. There are times when this is exactly the thing to do. Simply blanket find/replacing calls of antcall probably is not the way to go.
    Macrodef is not a target. So you cann't not individually test the macro. You have to create another target which wrap the macro to test it.
    That's right. it's really a simple method for defining ant tasks, that are a collection of other ant tasks. Once it's gotten to the point where it's taking over the build file or cluttering things up, replace it with a real custom task written in Java. For me, the convenience of antcall and "tidiness" of it (which is debatable) is not worth its cost, but as you say, that's just my experience with it. If it works for you, use it (shrugs) and chalk it up to TMTOWTDI. Come to think of it, I feel pretty much the same way about Maven. I have a perfectly good build system now (that uses most of Maven's conventions in case I decide to take the plunge again in the future), including a pom file for dependency management, a mechanism for creating IDE project files, and much more besides, and I don't have to give up anything I currently have. It might be different story if I had to start completely from scratch each time -- but that hasn't been true for a long time. My build scripts and POM files are both extremely small and simple. The Maven2 build tool doesn't *currently* offer me anything that I don't already have or really need at the moment -- especially when I have the Maven2 plugin to give me the one or two things I wanted but didn't have. Glad to hear it's working out for so many folks though. I'll try it again when there is a Maven distribution that bundles most of it's core plugins with the tool that I can use "out of the box" without requiring an internet connection. (I belive such a distro is in the work for a price, which might be worthwile). For what it's worth to all the various Maven enthusiasts out there, I do see the attraction... really. I even buy in to the whole convention over configuration thing. I like the big ideas behind Maven and Maven2. I do dislike a few implementation details, and the current distribution model. I'll keep an eye on it for the future.
  32. Re: Top 15 Ant Best Practices[ Go to top ]

    I think this thread should have been called Ant v Maven. I have just created a Maven build for a project I am contracting on. Up until this point I have been using Ant. Here are my thoughts. (i) I like the idea of Maven but its documentation is patchy at best. Also useful examples of how to do anything other than a simple build are lacking. (ii) People say it is quicker to get a project going with Maven. I have re-used the same ANT build script for the last four years on several different projects. Therefore this is not an issue for me. (iii) If you are an company with lots of different projects and you want to standardized the builds and release process I would use Maven. However I would state you would need a build/release engineer to manage it all.