Discussions

News: Featured Article: Ant 1.6 - finally a real build tool

  1. Mike Spille discusses his love hate relationship with the build tool Ant. Ant blew onto the scene, allowing people to run away from make in droves. Ant has it's own niggles, and Mike talks about the nice things in the latest Ant 1.6.

    Introduction
    Like many other people, I've had a love-hate relationship with ANT for sometime now. On the plus side, ANT did away with a whole lotta nastiness that was associated with Make files. The tabs, the colons, the incompatibilities across operating systems, the embedded shell script hacks - all that is gone now. But unfortunately, ANT didn't exactly usher in a golden age of build systems. It's got its own quirks and flaws and design oddities that we've had to live with for some time - the endless unreadable XML, the lack of scripting capabilities (sorry, an ANT task written in Java isn't a script :-), and of course the lack of modular constructs. On the latter, the few anemic nods to modularity have basically sucked, and has lead over and over again to people creating many big build.xml files that are mostly identical, and with little chance for creating corporate/departmental/project build standards beyond offering a reference build.xml file - and instructing developers how to do cut and paste on their OS of choice.
    Read Mike Spille in Ant 1.6 - finally a real build tool

    Threaded Messages (52)

  2. Before anyone else does it ...

    "He likes it! Hey, Mikey!"

    For those who don't know - http://www.tvacres.com/admascots_mikey.htm
  3. What about Maven?[ Go to top ]

    It seems that all of Mike's complaints about ANT are satisified by Maven. I've only been using Maven a few weeks now, but after using ANT on several projects I'm already very impressed. Using Maven lets me separate our project into multiple subprojects. Each subproject inherits from a master project file so the information for each project is a bare minimum. And Maven supports Jelly, satisfying Mike's request for a scripting language. I must admit so far I haven't used Jelly.. I haven't needed to because Maven's features are so complete! And the site documentation Maven generates is awesome. I showed it to some people at my company and they were speechless. They were impressed, and of course I didn't show them how my maven project files were almost empty.

    Michael
  4. What about Maven?[ Go to top ]

    I played with Maven a little tiny bit, and also have talked to people who use it alot, and monitored a bunch of developer lists for projects using Maven (not the Maven list - projects which are using Maven). The consensus I've seen is that Maven is slow, buggy, and over-complicated. And Jelly is such an abomination that even the author has apologized to the Java community for creating it ;-) Looking on developer's lists, many of them a littered with poor people having Maven problems.

    Maven seems to mostly pull people in for the reason you state "...the site documentation Maven generates is awesome". It's an instant "wow!" factor. The problem is - most of that information is useless or goes completely ignored by people.

    Prior to ANT 1.6, ANT had enough holes that it gave an opening for Maven to exploit. Now that 1.6 is here, I see no reason for Maven to exist anymore. ANT isn't anywhere near perfect, but it's reached the critical point of "good enough".

        -Mike
  5. What about Maven?[ Go to top ]

    Nice post on Ant Mike.

    Strong agreement on maven. Consider this - I haven't seen a week go by on geronimo-dev without somebody unable to build the code out of maven due to some oddity or quirk. That's a ridiculous state of affairs.

    Maven's a mess any way you look at it and I expect it'll go the way of Jelly in due course - best guess being that it'll be replaced by a Groovy build tool calling out to Ant tasks.
  6. What about Maven?[ Go to top ]

    Well, I for one am not convinced based on some consensual decision from who knows who - I would appreciate hearing from more people about Maven who have actually used it for a period of time, recent experience is best. And, no offence Mike, but a die hard command line guy that used it a tiny bit is not the best judge. Monitoring lists is fine, but personal experience is, uh, (a la MC) priceless ;)

    As well, I haven't tried Jelly, is it really that bad?

    -Mark Waschkowski
  7. What about Maven?[ Go to top ]

    Mark - what can I say? I used it a tiny bit and hated it. Other people who's opinion is usually sound bitch about it. As another poster related, the geronimo list is littered with people who've been bitten by Maven nasties.

    The people who like it? They appear to fall into one of three camps:

      - People who always use the defaults and nothing else
      - Ultra-die-hard people who have gone to extraordinary efforts to do simple things outside of Maven's defaults
      - Maven developers :-)

    You yourself might want to read some development lists for real projects - what you'll read there are real developers solving real problems. That sort of info is alot more useful and pragmatic than getting someone's opinion here.

         -Mike
  8. Dependencies[ Go to top ]

    I honestly haven't used Ant in a very long time so this may be a dumb question, but does Ant have a better way to manage dependencies yet? That is one thing that I really like about Maven. I hate thinking about where my dependencies are or putting them into my project repository.
  9. What about Maven?[ Go to top ]

    Maven does have a bunch of gotcha's but we've been using it to build about 7 applications with another 12 odd dependent libraries for a rather large multinational. Our experience with maven has encouraged other groups to move away from custom built ant scripts. It did take some time to learn how to cut with the grain using maven but these are the benefits:

    - Standardisation, standardisation, standardisation. If you have a bunch of projects delivered by different teams, unless you have rigourous standards in place or only one guy who writes your ant scripts a _lot_ of ugliness ensues. If you have one guy who writes your build scripts, nobody else wants to touch them (and probably shouldn't).
    - Multiproject builds. Yeargh, this is where ant encourages the scariest kinds of things and <import> or entity references are friendliest of the bunch (whoooo ant 1.6 is a real build tool because you can statically import another ant build file... this is the same kind of thinking that confuses <include name="*.jar"/> for dependency management). ant genius's out there actively encourage things like using xslt to generate build.xml files for multiproject builds. In maven it's "maven multiproject" or <maven:reactor> if you're feeling brave.
    - Versioned dependencies. Maven encourages you to use versioned dependencies (whether they're your own or someone elses). Relying on versions in manifest files is painful at best and pretty hopeful most times. Actually knowing what your dependencies are is remarkably refreshing.

    That isn't to say that there is anything wrong with a well written ant build script (or bunch of ant build scripts), maven has just proved useful to me (and others) working on some real projects.
  10. What about Maven?[ Go to top ]

    Well, uh, Random - how much of what you said really applies now that ANT 1.6 is available? I agree that prior to 1.6 there was alot of ugliness for something that should have been built in (<import> should have been in 1.1). But now? As I said, I think the case for going Maven has been greatly weakened.

    On dependency management - all I can say is that ANT and Java are giant leaps forward in that regard compared to C and C++. Yet again, ANT 1.6 hits the "good enough" mark for me.

        -Mike
  11. What about Maven?[ Go to top ]

    Mike, your three Maven camps cross over a lot.
    - I use the defaults and nothing else on some projects because there is no point changing them when you don't have to. It's nice to at least have defaults to save some typing
    - I am a Maven Developer (but I was a user first)
    - I have extrodinarily complex things outside of Maven's defaults with relatively simple efforts before I was a Maven Developer.

    The camp that tries to do simple things the hard way does exist, but that happens everywhere in programming. I don't see why Maven should be any different. Better documentation on our part could certainly help in this area and that's now very high on the agenda.

    I'll fully admit that Maven has warts and we are working in the long term to remove them. The main problem we face during the RC-phase is that some users have piggybacked the warts and now depend on their existence :)

    I don't quite get why you think this will be the end of Maven or why Maven needs to die, but I've just posted a blog entry hoping to gather feedback on why this is. I'd love to hear from you!
  12. What about Maven?[ Go to top ]

    My case against Maven is quite simple - it's too big and attempts too much, and ANT is good enough for me. With only a few exceptions, whatever feature Maven might have, I can easily do it in plain old ANT. And with ANT 1.6, I can easily do it in a per-company, per-group, or per-project manner so that anyone using the appropriate level ant build file automatically gets that functionality.

    I'm sure Maven people must _hate_ this argument, but it's the most powerful one available - if something is "good enough", providing a higher level tool with alot more complexity is almost always going to be a losing proposition. The value-adds that Maven has aren't weighty enough to overcome ANT's "good enough".

         -Mike
  13. What about Maven?[ Go to top ]

    My case against Maven is quite simple - it's too big and attempts too much, and ANT is good enough for me. With only a few exceptions, whatever feature Maven might have, I can easily do it in plain old ANT. And with ANT 1.6, I can easily do it in a per-company, per-group, or per-project manner so that anyone using the appropriate level ant build file automatically gets that functionality.I'm sure Maven people must _hate_ this argument, but it's the most powerful one available - if something is "good enough", providing a higher level tool with alot more complexity is almost always going to be a losing proposition. The value-adds that Maven has aren't weighty enough to overcome ANT's "good enough". -Mike
    Certainly a fair argument Mike, but there are other 2 sides to this:
    - you're assuming you already know Ant. Faced with a choice to learn how to write a build script or how to write a project descriptor if all you are doing is building a jar file and running some tests, the descriptor is easier. Even if you know ant there is less work in building a project descriptor for a new project (even if you are copying and pasting then customising), and its easier to share and maintain.
    - you're assuming that what is "good enough" for you is "good enough" for everyone, and calling for a coffin to be wheeled out for Maven. We have users building a large number of projects that are interrelated. I don't think that Ant would be cut it for them any more in terms of maintenance and adding new projects.

    So I can agree with the good enough argument to an extent, but I think the incentives are still there for something better, even with Ant 1.6.
    Even after I'd only been using Maven for a matter of weeks, there was no way I was going to cut and paste scripts for ant again to do the simple things.
  14. What about Maven?[ Go to top ]

    Brett, I don't think you really get what <import> is bringing to ANT. My one-off ANT scripts can be cut down to about 4 lines if I use my build_common.xml. Sure, I know ANT and had to create that build_common.xml, but now I the "price" for doing a one-off project is trivial. The differnce is that _I_ understand build_common.xml, and it defines a structure - hmmm, curiously like Maven, except it's my structure and easy to control and understand.

    I predict pretty soon you'll see standard importable build scripts on the net that do similar things to my build_common - only more generic and useful :-) And what you're going to find is that a simple <import> is easy to understand and gets you 90% of what Maven people crow about. Maybe some whacko might even do the pretty-web site generation as an importable build file.

    You might not think that ANT is up to larger tasks, but again I think you're _way_ underestimating the impact that <import> and <macrodef> will have.

        -Mike
  15. What about Maven?[ Go to top ]

    I can see the direction it is taking, and I wonder how much it will take off. You're right - it's easy to use, and I've been there and done that with ant - very complicated stuff that used XML entities instead of <import/>. Import sounds like it makes this easier - which is great. I don't think I'm underestimating the impact it has though. As soon as people start sharing their Ant script solutions for things its going to have exactly the same trade offs Maven has about flexibility - and this will limit their take up. Users will continue to roll their own.

    I certainly don't crow about Maven's plugin ability at anywhere near the level of 90%. The structure they provide is great for extending and providing a consistent way to reference them, and is more powerful than import if you need it. But its really just the means to an end, not what Maven is all about.

    Maven is all about project management. Centralising information about the project including the build. It allows you to extend based on metadata rather than on build fragments, and then you've got source control, dependency management, release management, continuous integration, website generation, reporting and whatever else people come up with.

    If ant does what you want and you are happy to use it, then each to their own - there's no reason to learn something new for the sake of it. But I think your jibes at Maven were off the mark and like it or not its here to stay :)

    But thanks for the response - I've enjoyed the discussion and the opportunity to think hard about why I use Maven again rather than why I develop on it :)
  16. What about Maven?[ Go to top ]

    Brett, your first paragraph is wrong and I'll tell you why: just about anyone can see what <import> does, and just about anyone can call up the imported file and pretty easily understand what it does. This doesn't fly at all for Maven - as someone else said, when you peek under the covers it's daunting in complexity.

    Take another gander at my simple build_common.xml file - it's practically brain dead, yet it allows me to write 4-line build files. You will see sharing of "commodity" build files because fundamentally ANT is pretty simple. The knowledge you use in a typical build.xml file is instantly transportable to an <imported> build file. Can you say the same for Maven? Is using a default descriptor and creating a new one, or modifying someone else's, just as easy?

    This dives into something I said on one of the Groovy lists. Many scripting languages suck because they have an "effort" timeline of:

       easy task (almost no effort) --- slightly more complex task (an order of magnitude more effort) --- a typical complex IT task (18 orders of magnitude more effort)

    (with a smiley on the last!). That is - easy things are really easy, because the defaults are tuned to make common tasks brain dead. Slight more complex tasks need an order of magnitude more effort - because you need to understand some of the magic that the defaults hid from you. Typical complex tasks require many magnitudes more effort - because suddenly you're fighting the defaults, and you rapidly learn that to do something "complex" requires you to know _everything_.

    Non-scripty languages - like Java - don't have this sort of learning curve because there's alot of regularity and little magic. Your complex tasks end up being composition of easier tasks using the same basic building blocks.

    ANT is like that. There may be an initial pop to learn the building blocks, but then you're done.

    Maven is like those scripting languages - the easy is dead easy, things that deviate from the defaults suddenly require you to learn alot more, and complex tasks require you to know everything about everything. There are nasty, big discrete steps between different levels of use.

    I wrapped up my little language/script discussion by saying this: in something like Java, there's an intial pop, sure - but there are no real gurus. There can't be - nothing is hidden, a 500 line program is going to use no more or less of the language than a 50,000 line one. Scripting languages, like Perl, are breeding grounds for gurus, because your 50 line script looks _nothing_ like your 5000 line script. To go from 50 lines to 5000 requires a monumental guru-like leap.

    Maven is like that - the Perl of Java build systems. A breeding ground for gurus. I don't want to be a Perl guru, and abandoned it for Groovy. I don't want to be a Maven guru, and I abandoned it for ANT 1.6. Maybe you're into the esoteric knowledge required to master these sorts of things, but I just don't have the time.

         -Mike
  17. What about Maven?[ Go to top ]

    Brett, your first paragraph is wrong and I'll tell you why: just about anyone can see what <import> does, and just about anyone can call up the imported file and pretty easily understand what it does. This doesn't fly at all for Maven - as someone else said, when you peek under the covers it's daunting in complexity.
    Sorry I'm not coming across very clearly. I can't argue with this at all, but its not the only use case.

    If you are talking about making your own reusable build fragments: you can just as easily do an import in Maven as you can write your own plugin depending on what you are trying to achieve.

    But you're also talking about fragments written by 3rd parties that you reuse. I'm not sure how these are distributed
     - do you download and add them to your own repository, and end up stranded with any future enhancements or bugfixes?
     - do you automatically pull them from a URL and suffer the consequences if they change/disappear?
     - I've seen something about ant libraries beginning in 1.6 which are starting to look a lot like Maven plugins

    Now its fair that the complexity is daunting at first when you look into the plugins. Once you've found what you want it is quite simple. We can certainly alleviate this with better documentation and removing some of the magic, which is progressing now.

    But in most cases you don't care. Assuming its not buggy and its interface is well documented (a big assumption, but one that would also be required if you are making generic Ant build fragments), you don't need to know how maven jar works, you just know you gave it your sources and it built the jar just how you like it. If you aren't trying to build a jar, you don't use it.
    Take another gander at my simple build_common.xml file - it's practically brain dead, yet it allows me to write 4-line build files. You will see sharing of "commodity" build files because fundamentally ANT is pretty simple.
    Agreed, but I don't see how this is any different to cut-and-pasting it out of an article or using an XML entity to include it the old fashioned way.
    Is using a default descriptor and creating a new one, or modifying someone else's, just as easy?
    Yes. Tell me you don't know what <sourceDirectory/> means.

    But if you mean the magic behind how that creates a JAR, you really don't want to know what the plugin does to build the JAR in the same way you don't care how Ant's <jar /> task compiles it from a bunch of classes either. Just because it is a different level of granularity doesn't mean it is any different.
    Typical complex tasks require many magnitudes more effort - because suddenly you're fighting the defaults, and you rapidly learn that to do something "complex" requires you to know _everything_.
    Sorry, but I can't agree with this. You leverage the defaults where it suits you and you override it when you want. With Maven you always have the choice of completely circumventing any of the plugins if you really want to script your own jar creation. But if you find something that takes the inputs you have and the outputs you want, you hook into that and go on your merry way.
    Non-scripty languages - like Java - don't have this sort of learning curve because there's alot of regularity and little magic. Your complex tasks end up being composition of easier tasks using the same basic building blocks.ANT is like that.
    Many of the plugins reuse functionality from existing plugins to avoid doing it themselves. They become the building blocks.
    Maven is like those scripting languages - the easy is dead easy, things that deviate from the defaults suddenly require you to learn alot more, and complex tasks require you to know everything about everything.
    I think you are teasing out this valid point to the extreme. The complex tasks mean you must know everything about everything that your tasks will encompass. The same will occur for your complex ant build (except that you probably wrote it yourself consuming more time than learning what someone else did).
    in something like Java, there's an intial pop, sure - but there are no real gurus. There can't be - nothing is hidden, a 500 line program is going to use no more or less of the language than a 50,000 line one.
    So you never code with any third party libraries? It's almost exactly the same thing.

    In a development prototype of Maven, some plugins are written in Java. Does that mean that they automatically become easier to understand than bits of Ant tied with scripting? No.

    We can certainly argue back and forth about the merits of <import/> vs. reusable plugins, but it still glosses over large portions of what Maven is. It is not just a scripting/plugin framework. It provides a bunch of services to maintain and use project structure. For example, artifact handling: how to get dependencies, and how to deploy generated artifacts to share. That's all sorted out before you even think of looking at the build script.
  18. There is one more feature related to <import> in Ant 1.6 -- you can "override" targets. For example, if you have a "compile" target in build_common.xml you could also define "compile" target in the project's build.xml (which imports build_common) and have extra processing before or after you invoke build_common.compile.

    In some way it is similar to Maven's preGoal/postGoal feature.
  19. Ant 1.6 is like Maven[ Go to top ]

    So if Ant 1.6 has <import> which is something like Maven's reactor and reusable plugins, and it has an 'override' facility like Maven's pre/postGoal then at least it shows that people advocating Maven had a good point all this time! After all Ant had to add such features too!

    That leads to this question: it seems some people think Maven is a good idea with a bad implementation? Ant tries to copy at least some of the ideas, so it must be a good idea.

    Anyway, I prefer Maven, and the main reason is Jelly. With Maven I have a relatively easy way of scripting reusable plugins. We use it. We have many custom reusable plugins. With Ant I can't even do a simple for/if/else in most cases! Maven's alleged complexity pays off, imho, when you have different projects and subprojects.

    Ara.
  20. Ara, I wouldn't say that ANT 1.6 is copying Maven. What's it's providing is something that just about every other build system in existence has, and what ANT should have had from the beginning. If you want to say that ANT copied anything from anyone, you'd be more on the mark to say that ANT copied Make's Makefile inclusions.

         -Mike
  21. Ant 1.6 is like Maven[ Go to top ]

    So if Ant 1.6 has <import> which is something like Maven's reactor and reusable plugins, and it has an 'override' facility like Maven's pre/postGoal then at least it shows that people advocating Maven had a good point all this time!
    No arguments there, and this was pretty much my reaction the first time I read Maven's documentation and description of the project.xml file. Awesome idea!

    Then I actually tried it and ended up on the same path as Mike after I failed to transfer my current projects over to Maven.

    The idea of capturing a project layout in one central file is great, but I think it can be implemented in a more intuitive way that what Maven provides.
    Anyway, I prefer Maven, and the main reason is Jelly.
    Ah sorry, can't help you there.

    I know of a few people who can, though.

    --
    Cedric
  22. No arguments there, and this was pretty much my reaction the first time I read Maven's documentation and description of the project.xml file. Awesome idea! Then I actually tried it and ended up on the same path as Mike after I failed to transfer my current projects over to Maven.

    The idea of capturing a project layout in one central file is great, but I think it can be implemented in a more intuitive way that what Maven provides.
    I have to agree with Cedric here. On paper, Maven sounded great. But when I tried to incorporate into an existing project, it was a beast. Our project has generated configuration files, generated source code, configurable properties per environment, etc. I could never get Maven to play nice with the existing structure - it always wanted to use its structure, not mine.

    A co-worker of mine insists that Maven is usable. Perhaps he is right. If it is, the documentation does not help demonstrate this at all. And with all software - it a feature isn't documented, it doesn't exist.

    Off to check out Ant 1.6...

    Ryan
  23. On paper, Maven sounded great. But when I tried to incorporate into an existing project, it was a beast. Our project has generated configuration files, generated source code, configurable properties per environment, etc. I could never get Maven to play nice with the existing structure - it always wanted to use its structure, not mine.
    Have a look at antworks in the near future (http://antworks.sourceforge.net).
    Some features:
    - importing build modules (antlet) from a remote repository
    - standardized antlets (eg. checkstyle, junit, pmd, jdepend, forrest are allready available)
    - use a project descriptor or use property files to describe your project and
      control the build modules (your choice).
    - it offers smooth migration for existing projects, because everything (except the importer task) is standard ant.
    - you can start using a minimum of antworks and while continuing your project move features to standard build modules or move to the standard modules that are offered by antworks
    - project dependencies are tracked by the project descriptor and by Apache Depot (incubator status, formerly known as Krysalis Ruper).

    We're still in pre-alpha status, an alpha release will be available in a few weeks. As you see a top-level portal will still have to be setup on antworks and we're in need of how-tos and additional documentation.

    In CVS a seed antlet is available that seeds helloworld type of projects for jar/war (ear is in-the-make) projects that give an idea of how antworks can be used.

    Michael
  24. Looking a little closer[ Go to top ]

    I have to agree with Cedric here. On paper, Maven sounded great. But when I tried to incorporate into an existing project, it was a beast.
    it always wanted to use its structure, not mine.
    Its true. Its far more difficult to integrate it into an existing project - as it is making some assumptions regarding the way you want to build. That said, none of the changes I have had to make in doing this have been bad changes.
    Our project has generated configuration files,
    <preGoal name="java:jar-resources">
       gen config
    <preGoal>
    generated source code,
    <preGoal name="java:compile">
       gen code
    <preGoal>
    configurable properties per environment,
    Have a goal-per environment - and set a property:
    <goal name="dev:build"
            description="Creates a development deployment unit (zip)">
            <j:set var="deployment.environment" value="dev-"/>
            <attainGoal name="dist"/>
    </goal>

    In your pre-goal where you generate your config, it can look at the property that is set and gen the right config...

    -Nick
  25. There is one more feature related to <import> in Ant 1.6 -- you can "override" targets. For example, if you have a "compile" target in build_common.xml you could also define "compile" target in the project's build.xml (which imports build_common) and have extra processing before or after you invoke build_common.compile.In some way it is similar to Maven's preGoal/postGoal feature.
    Wow, around aspects in ant!

    Next on the list: <pointcut target="compile"> :-)

    --
    Cedric
  26. Wow, around aspects in ant!
    Or preGoal and postGoal as its known in maven...
  27. The differnce is that _I_ understand build_common.xml, and it defines a structure - hmmm, curiously like Maven, except it's my structure and easy to control and understand.
    Hummm.... it smells like the "Not Invented Here" Syndrome!
    http://www.developer.com/design/article.php/3338791
  28. My experience.[ Go to top ]

    I've tried maven and have to agree with Mike. I had a look at some of those jelly/xml files that drive the whole thing. They looked to be hideously complex, thats when I decided to give up.
  29. I don't see why Maven should be any different.
    There is one big feature (beside other minor ones) that I'm missing in Maven: support for transitive dependencies.
    I don't want to track the dependencies of all subsubsubprojects by myself. I only want to declare the direct dependencies of my build units and the build system should do the remaining work.

    I can't imagine why you want to publish the 1.0 final version without this great feature, that would be great benefit compared to ant.
    I wrote a little jelly plugin for this and I know there is an experimental patch on the Maven developer site.
    I hope we will see it in 1.1.
  30. What about Maven?[ Go to top ]

    I played with Maven a little tiny bit, and also have talked to people who use it alot, and monitored a bunch of developer lists for projects using Maven (not the Maven list - projects which are using Maven). The consensus I've seen is that Maven is slow, buggy, and over-complicated. And Jelly is such an abomination that even the author has apologized to the Java community for creating it ;-) Looking on developer's lists, many of them a littered with poor people having Maven problems.Maven seems to mostly pull people in for the reason you state "...the site documentation Maven generates is awesome". It's an instant "wow!" factor. The problem is - most of that information is useless or goes completely ignored by people.Prior to ANT 1.6, ANT had enough holes that it gave an opening for Maven to exploit. Now that 1.6 is here, I see no reason for Maven to exist anymore. ANT isn't anywhere near perfect, but it's reached the critical point of "good enough".    -Mike
    So far, I don't think ANT 1.6 has the same features as Maven. With Maven, if your project is structured in a "best practices" format, you benefit from an automated build without writing the build file. With ANT 1.6, each project must still write code to create jars, compile, launch unit tests, etc. Imagine 1,000 java projects all writing the same thing. Doesn't it make sense to replace 1,000 build.xml files with Maven??

    Don't get me wrong, I like ANT. And with ANT 1.6, ANT provides the features necessary to do an automated build. However, there is still a bit of work to do in setting it up. With Maven it's automatic. For me the difference is like writing your own logging class instead of using Log4J. Why write your own build files when they're already written??

    Michael
  31. What about Maven?[ Go to top ]

    So far, I don't think ANT 1.6 has the same features as Maven. With Maven, if your project is structured in a "best practices" format, you benefit from an automated build without writing the build file. With ANT 1.6, each project must still write code to create jars, compile, launch unit tests, etc. Imagine 1,000 java projects all writing the same thing. Doesn't it make sense to replace 1,000 build.xml files with Maven??
    There is no such thing as a "best practices" project structure. I think you've been sipping a bit too much of the Maven Koolaid :-)

    If there is a project structure which seems sensible as a default, I think you will fairly quickly see a consensus build_common.xml pop up on the net. If you don't see such a beasty, that to me would indicate that there is no such thing as a sensible default, and people _prefer_ to define their own structures and have their own master builder files.

    You're also making a mountain of a molehill here - as I said in my blog entry, ANT build files are hardly rocket science. You're projecting a complexity on them that just isn't there.
    Why write your own build files when they're already written??
    Maybe because there is a wide diversity of projects out there and creative thought going into how different people want to structure their builds? Maybe because a cookie cutter approach doesn't work for many people?

        -Mike
  32. What about Maven?[ Go to top ]

    Any build system that assumes a "best practices" project structure is pretty much doomed to failure. In the real world (not toy open source projects), very few products are architected around a simple model of "source goes here, tests go here", etc. In my job at a large telco provider, I've evaluated the quality of many different software systems, some small, some extremely large. One thing that always strikes out at me is that no two build systems are ever the same. They may use 'make' under the hood, but directly layouts, processing rules, configuration management interactions and third party source trees are all handled differently. Writing a build tool to gracefully handle all of these situations would be maddening.

    The Java community likes to experiment with new ideas and that's generally a good thing, but it might be worth taking a look at our cousins in the C/C++ world to see what's going on. There is a reason 'make' has survived more or less untouched for more than twenty years. It has acknowledged limitations, particularly in regards to cross platform support, but it hits the sweet spot of targets, dependencies and macros rather well. More complex approaches have always been handled by layering on scripting when necessary, or with packages like GNU autoconf/automake.

    There is something to be said for straightforward solutions that solve 80% of the problem. We don't always need to boil the ocean.
  33. What about Maven?[ Go to top ]

    Any build system that assumes a "best practices" project structure is pretty much doomed to failure. In the real world (not toy open source projects), very few products are architected around a simple model of "source goes here, tests go here", etc.
    I agree - we have no less than 10 different layouts at our place because of the age of projects and the effort required to restructure them.

    That said, they all use Maven. It doesn't assume a structure, it assumes a best practices default. The whole lot is still configurable.

    The trick really is documenting this in a useful way and is something I'm working on now.
  34. What about Maven?[ Go to top ]

    Also don't forget that Maven is a very young project, whereas ANT has been around for 4 years. ANT just now added the concept of importing a build.xml file whereas Maven has had that since the beginning. I agree with one thing in your article, ANT stopped evolving. In my opinion they dropped the ball. They could have evolved ANT into what Maven is today but they didn't. And that's why Maven came along.

    Also lots of people are complaining about the fact that ANT uses XML instead of a scripting language. And I agree with this. Implementing conditional logic in XML is not the best solution. Why do we do it? Because ANT has been around for 4 years and is a defacto standard. Maven made a good attempt to improve on this with Jelly, but I agree Jelly isn't the best choice and whoever mentioned Groovy has a good idea. But my point is ANT is stuck in XML and Maven is trying to go farther.

    Michael
  35. What about Maven?[ Go to top ]

    Also don't forget that Maven is a very young project
    Maven has been around longer than Hibernate. It should be very mature by now. I don't think you can use "youth" as an excuse for its warts.
    I agree with one thing in your article, ANT stopped evolving.
    Sometimes, projects stop evolving - or at least the evolution slows - because they reach a point where they do 98% of the things that 98% of users really want. I would say that ANT reached that point. Of all the tools I use to do development, I would say that Ant is the one I bitch about least often, the one I don't need to think about, because it Just Works.
  36. What about Maven?[ Go to top ]

    Maven has been around longer than Hibernate. It should be very mature by now.
    +10

    -Nick
  37. What about Maven?[ Go to top ]

    Maven has been around longer than Hibernate. It should be very mature by now. I don't think you can use "youth" as an excuse for its warts.
    I agree too. It was unfortunate, but development (and developer interest) went south for the better part of last year.

    But things are back on track and now and the plan forward is much stronger. We've cut the changes that we know won't be fixed without big implications for users and put them into a "new development pile", starting from scratch. The current release candidates have not introduced any esoteric features and have focused on cutting memory usage, backwards compatibility with RC1 (all known problems have been fixed), and now improving the documentation.
  38. What about Maven?[ Go to top ]

    Also don't forget that Maven is a very young projectMaven has been around longer than Hibernate. It should be very mature by now. I don't think you can use "youth" as an excuse for its warts.
    Certainly not if it comes to code quality. And certainly yes if it comes to maturity of ideas which are implemented: we are disovering new paths and of course making mistakes.
    For example there is quite big difference between maven and hibernate.
    We didn't have that many books and theoretical background (OR mapping is almost 15 years old!) to learn from nor projects from which we can steal ideas or code (like OJB served as inspiration for hibernate).

    Maven reflects collective experience of group of developers and represents their "philosophical" beliefs in what's good what's not.
    Maven is not trying to make a whole world happy and just include some nasty futures because group of people is demanding them.

    That's why maven developers has a label of being arrogant. Maybe we are but we never meant to be popular...



    Michal
  39. What about Maven?[ Go to top ]

    Also don't forget that Maven is a very young projectMaven has been around longer than Hibernate. It should be very mature by now. I don't think you can use "youth" as an excuse for its warts.
    Certainly not if it comes to code quality. And certainly yes if it comes to maturity of ideas which are implemented: we are disovering new paths and of course making mistakes.
    For example there is quite big difference between maven and hibernate.
    We didn't have that many books and theoretical background (OR mapping is almost 15 years old!) to learn from nor projects from which we can steal ideas or code (like OJB served as inspiration for hibernate).

    Maven reflects collective experience of group of developers and represents their "philosophical" beliefs in what's good what's not.
    Maven is not trying to make a whole world happy and just include some nasty futures because group of people is demanding them.

    That's why maven developers has a label of being arrogant. Maybe we are but we never meant to be popular...



    Michal
  40. Yay, A maven bitch-fight[ Go to top ]

    I have used Maven and Ant, and I have to say that I prefer Maven... (just)

    Why?
    Here is a list I prepared earlier:
    1) For a simple build, its purely declarative. No scripting (or your money back).
    2) For a more complex build with non-standard artifacts, the only fancy stuff I have to script is... the fancy stuff (and there usually isnt much)
    3) Ant scripts, without some XML hacking, become a manifestation of duplication and a maintenance headache.
    4) You can be guaranteed that no two ants scripts are the same. Not even remotely. From project to project or even within a project. The targets names are wildly different, the structure and style and readability are different. And practically every one you see has some form of ant blasphemy in it. Simply put: too much rope for a simple build.
    5) The messing about you have to do when you are using extra "plugins" is a bit of a pain.
    n) Last but not least, with Maven you get a free website, with a known & sensible structure, and a decent centralisation of project information. (great for OSS projects and corporate projects alike)

    That said, there are plenty of things I dont like about Maven:
    1) The project team have incredibly wonky priorities. They have a complete aversion to doing releases or supporting/updating released versions. They dont seem to have a good grasp of what is important.
    2) Rather than complete plugins, they embark on "refactorings" and adding new features of dubious worth.
    3) There are prescious few examples and documentation. Nothing to compare to ant's documentation. The plugin documentation (you want to know what a fecking goal does, without having to look at the jelly!) is crap at best.
    4) I see issues in their Jira dating back many many moons - not closed. I see valuable contributions .. unused.
    5) Buggy? RC1 and RC2 are a breath of fresh air compared to previous releases. These have been the only releases where Maven has "just worked" for me. I was ready to give up on maven before these releases. That said, some plugins are a bit broken - but no-one seems to want to fix them...

    |
    |And Jelly is such an abomination that even the author has apologized to the
    |Java community for creating it ;-)
    |

    Jelly is in abomination and Ant isnt?? Given that Jelly is a superset if Ant, what abominable non-ant jelly features would you use for a project build that would make it more crap than ant?? They are both good for this purpose.

    I have a bone to pick with James about this: He shouldnt have apolagised for Jelly - in fact, it was a bit silly that he did (because then people start using that to prop up their various arguments against XML, Jelly, Ant, things that use Jelly). Jelly is useful. Not in the way Groovy is... but that isnt a surprise and it doesnt make it automatically crap.

    The entertaining thing I see, is that some maven-bashers use "foreach" etc plugins for ant... ha ha ha. Jelly in all but name...

    -Nick
  41. Still waiting for a better tool[ Go to top ]

    Ant still lacks a good (and I mean "good" not "sorta okay") graphical way of editing a project. Theres a few attempts out there but they all still suck. I guess you could say Make is in the same boat.

    Ant also has problems in that the development team keeps changing the tags. This is real frustrating since they leave no transition tool to move older ant builds to work with newer ant versions. Hello: XSL!! Come on guys, before you come out with the next a greatest version dont release unless you can migrate people.
  42. Still waiting for a better tool[ Go to top ]

    http://www.openmake.com/products.html
    Not OSS. But close to what you are asking for?
  43. Still waiting for a better tool[ Go to top ]

    (this was posted before by someone)
    FireAntz - http://dev.eclipse.org/viewcvs/indextech.cgi/%7Echeckout%7E/ecesis-home/resourceLibrary/downloads/iceContest/65%20FireAntz.zip
    http://dev.eclipse.org/viewcvs/indextech.cgi/%7Echeckout%7E/ecesis-home/resourceLibrary/downloads/iceContest/iceContestWinners.html
  44. Still waiting for a better tool[ Go to top ]

    I'm an old world Unix style command line bigot. The idea of a graphical build tool is....alien.

    Plus - with things like <import> and <macrodef>, build files can become much simpler, and the types of problems you cite will hopefully lessen.

        -Mike
  45. Try IntelliJ-IDEA support for Ant file editing: it does autcompletion, CTRL+B jumps to target definition, highlights undefined properties.
    Very convenient, I could not imagine what else I need from Ant file editor.
  46. Try IntelliJ-IDEA support for Ant file editing: it does autcompletion, CTRL+B jumps to target definition, highlights undefined properties. Very convenient, I could not imagine what else I need from Ant file editor.
    Maybe the bugfixes and new features that hopefully will be included in the new 4.1 release. ;)
  47. Ant also has problems in that the development team keeps changing the tags. This is real frustrating since they leave no transition tool to move older ant builds to work with newer ant versions. Hello: XSL!! Come on guys, before you come out with the next a greatest version dont release unless you can migrate people.
    Do you have elements to underline this 'keep changing the tags' assertion that leaves your build useless when you upgrade to a new version ?

    btw, I created this update stylesheet 2 years and 3 months ago. It has only been changed once.

    http://cvs.apache.org/viewcvs.cgi/ant/src/etc/ant-update.xsl
  48. ant <import> and xml entities[ Go to top ]

    Before the ant 1.6 import task we used to accomplish the same goal with the use of XML entities. Basically, we would define an entity corresponding to the common file and then import it. The equivalent code to the example in the article, with the differences in boldface, would have looked something like this:


    <?xml version="1.0"?>
    <!DOCTYPE project PUBLIC "-//PNP//BUILD DTD/EN" [
    <!ENTITY build_common SYSTEM "../build_common.xml">
    ]>

    <project basedir="." default="compile" name="EmberIO">

    <!-- ========== Executable Targets ======================================== -->

      <target description="Initialize environment" name="project_init">

        <property name="component.name" value="EmberIO"/>
        <property name="component.package" value="pyrasun"/>
        <property name="component.title" value="Pyrasun EmberIO"/>
        <property name="component.version" value="0.1_Alpha"/>
      </target>

      &buildcommon;
     

    </project>

    It is not as neat as the <import> statement, but it works.
  49. ant <import> and xml entities[ Go to top ]

    Alexandre, there were various things you could use with ANT to sort-of get <import>. People have cited XML entities; I myself used antmerge. The problem is that these were always "sort-of" solutions. With ANT 1.6 the notion of build file composition/inheritance is a first class construct. And making it a first class citizen makes all the difference in the world in getting people to start doing things sensibly.
  50. Ant is a metaphor for Java. Pretty good up to a point, after which it is very so-so.
  51. Ant 1.6[ Go to top ]

    Agreed - Ant 1.6 has some nice additions that go a long way to making Ant build files easier to manage and read. I wrote up my thoughts on it in January -- they may be coming out soon. ;)
  52. imports and scripting[ Go to top ]

    You can use xml entities as imports and the <script> tag has existed for quite some time now (beanshell being my first choice for the language attribute).
  53. Ant and modularity[ Go to top ]

    I have a number (double figures) of modules I need to build, with well-defined dependencies between the modules. For example, A may "depend" on B and D, while B depends on C and D.

    So, when I build A, I need to:
    1. Ensure B and D are built (but they should only be built once).
    2. Use the artifacts of B and D (e.g. JAR files, Java source for javadoc'ing, etc.) when building A.

    I want to be modular in defining each of these builds in their own file, instead of having 1 (huge) file containing build information for all modules.

    I guess I really want to have a higher level abstraction, that says "A depends on B and D", and then for my compile task to know how to construct the classpath when compiling A (i.e. include JARs from B and D). In ANT currently, I'd probably have to explicitly specify the JARs from B and D.

    It seems to me that ANT doesn't allow (or at least doesn't make easy) this sort of modularity. Reuse has maybe been addressed (at least to some degree) in 1.6. But the sort of modularity I want doesn't seem to be there.