While i'm developing in C/C++ and Java, i simply make a compile.bat script that does everything, that's fine for me. Why should i use make and why should i use ant?
Suppose you have 1000 source files and change just one of them. With your .bat script you will have to recompile the lot, with make you recompile just the one that changed. This can save quite a bit (read hours on a big project) of time.
Even better, if you change one of your header files, make will re-compile only the source files that use that header.
These are the two main features that have meant make and its offspring are used for all serious software development with compiled languages.
With a build file, you can automate more than just compiling your code; you can run unit tests, gather metrics, package build artifacts for deployment, and more.
An advantage, of sorts, of Ant is that it inspired tools for other platforms - NAnt for .NET, Phing for PHP. They do the same things, and work in the same way.
As long as you develop for yourself under Windows: suit yourself.
But if you start to develop with others Ant and Make are a standard to describe how your App is built.
There may be several reasons:
- because you are not the only one in the project
- because somebody will have to care about the build script when you left
- because a compile.bat script is not platform independent
- because the policy of the project defines the build technology, e.g. for the entire enterprise
I recently read a funny article about build tools. For you only the first part may be of any interest (before the maven bashing starts)
For one thing, make and ant both keep track of which files have already been compiled, so it does not redo work if it isn't needed.
You gain some platform-neutrality (how can I run your batch-script on my linux-box). But more important: build-tools have support for dependency-resolution. Scripts lack this and have to build it on their own.
Say you have targets A, B and C. B and C both depend on A. In an script they call the subroutine A. If you now create a new target D, that depends on B and C, than you will execute A twice. Build-tools recognize this and execute A only once.
Because this situation is typical for task involving compiling, building a distribution, testing, building documentation etc. build-tools are useful for software-development.
It would be possible to use a .bat file -- or bash or another flavor of shell script -- to do everything Ant can do, I believe. But it's far easier to do many things in Ant...
create/move/delete files and directories
apply filter tokens
run unit tests
package a jar, zip, or war properly
Many projects need to do these things, in addition to compiling, when they build.
Also Ant is platform-independent, so you can collaborate with those who use other operating systems.
But why stop at Ant? Apache Maven offers even more compelling features.
Make and Ant really come into their own when used with automated build systems or continuous integration.
The requirements for production builds, test builds and development builds are often different, and on a multi-person team, different developers set up their development environments in different ways.
Having a definitive build process solves the "Works on My Machine" (WOMM) problems that arise whenever the application needs to be built on a different machine from the one that it was developed on. It is the ultimate arbiter when one developer checks in code that doesn't work on another developer's machine. If the build process doesn't produce working software, then the first developer's check-in was broken. If it does produce working software then the second developer's development environment is broken - unless proven otherwise.
Related
I am attempting to port an application that was written with a combination of c++ for the back end, and java for the front end. This application relies on the library opencv 2.4.13, which is outdated, as well as multiple other libraries. The concern i have is that i do not want the end user to need to install these dependant programs, as they have been proving challenging to install on any but a select few linux distributions. I believe the term i am looking for is statically linking, but i'm a bit unfamiliar with c++ compilation at the moment, so i am unsure the steps i need to take to make these files portable. The java application requires these files to be libraries, and while i have managed to get them to compile on one machine, the problem seems to be getting them to run on a different one after compilation.
Don't bother - this might also give you licensing problems, depending on what libraries you need.
Instead, just figure out what platforms your application is supposed to run on and package the libraries for each platform with your jar - or download them at startup, or provide them as a separate package. The exact mechanics you choose depend on your use case, the point is you don't need to rely on system wide installs.
For past 4 years, I have been programming with Eclipse (for Java), and Visual Studio Express (for C#). The IDEs mentioned always seemed to provide every facility a programmer might ask for (related to programming, of course).
Lately I have been hearing about something called "build tools". I heard they're used almost in all kind of real world development. What are they exactly? What problems are they designed to solve? How come I never needed them in past four years? Are they kind of command-line stripped down IDEs?
What are build tools?
Build tools are programs that automate the creation of executable
applications from source code (e.g., .apk for an Android app). Building
incorporates compiling,linking and packaging the code into a usable or
executable form.
Basically build automation is the act of scripting or automating a
wide variety of tasks that software developers do in their day-to-day
activities like:
Downloading dependencies.
Compiling source code into binary code.
Packaging that binary code.
Running tests.
Deployment to production systems.
Why do we use build tools or build automation?
In small projects, developers will often manually invoke the build
process. This is not practical for larger projects, where it is very
hard to keep track of what needs to be built, in what sequence and
what dependencies there are in the building process. Using an
automation tool allows the build process to be more consistent.
Various build tools available(Naming only few):
For java - Ant,Maven,Gradle.
For .NET framework - NAnt
c# - MsBuild.
For further reading you can refer following links:
1.Build automation
2.List of build automation software
Thanks.
Build tools are tools to manage and organize your builds, and are very important in environments where there are many projects, especially if they are inter-connected. They serve to make sure that where various people are working on various projects, they don't break anything. And to make sure that when you make your changes, they don't break anything either.
The reason you have not heard of them before is that you have not been working in a commercial environment before. There is a whole lot of stuff that you have probably not encountered that you will within a commercial environments, especially if you work in software houses.
As others have said, you have been using them, however, you have not had to consider them, because you have probably been working in a different way to the usual commercial way of working.
Build tools are usually run on the command line, either inside an IDE or completely separate from it.
The idea is to separate the work of compiling and packaging your code from creation, debugging, etc.
A build tool can be run on the command or inside an IDE, both triggered by you. They can also be used by continuous integration tools after checking your code out of a repository and onto a clean build machine.
make was an early command tool used in *nix environments for building C/C++.
As a Java developer, the most popular build tools are Ant and Maven. Both can be run in IDEs like IntelliJ or Eclipse or NetBeans. They can also be used by continuous integration tools like Cruise Control or Hudson.
Build tools are generally to transform source code into binaries - it organize source code, set compile flags, manage dependencies... some of them also integrate with running unit test, doing static analysis, a generating documentation.
Eclipse or Visual Studio are also build systems (but more of an IDE), and for visual studio it is the underlying msbuild to parse visual studio project files under the hood.
The origin of all build systems seems like the famous 'make'.
There are build systems for different languages:
C++: make, cmake, premake
Java: ant+ivy, maven, gradle
C#: msbuild
Usually, build systems either using a propriety domain specific language (make, cmake), or xml (ant, maven, msbuild) to specify a build. The current trend is using a real scripting language to write build script, like lua for premake, and groovy for gradle, the advantage of using a scripting is it is much more flexible, and also allows you the to come up with a set of standard APIs(as build DSL).
These are different types of processes by which you can get your builds done.
1. Continuous Integration build: In this mainly developers check-in their code and right after their check-in a build initiates for building of the recent changes so we should know whether the changes done by the developer has worked or not right after the check-in is done. This is preferred for smaller projects or components of the projects. In case where multiple teams are associated with the project or there are a large no. of developers working on the same project this scenario becomes difficult to handle as if there are 'n' no. of check-in’s and the build fails at certain points it becomes highly difficult to trace whether all the breakage has occurred because of one issue or with multiple issues so if the older issues are not addressed properly than it becomes very difficult to trace down the later defects that occurred after that change. The main benefit of these builds is that we get to know whether a particular check-in is successful or not.
2. Gated check-in builds: In this type of check in a build is initiated right after the check in is done keeping the changes in a shelve sets. In this case if the build succeeds than the shelve-set check-in gets committed otherwise it will not be committed to the Team Foundation Server. This gives a slightly better picture from the continuous integration build as only the successful check-in's are allowed to get committed.
3. Nightly builds: This is also referred as Scheduled builds. In this case we schedule the builds to run for a specific time in order to build the changes. All the previous uncommitted changes from the last build are built during this build process. This is practiced when we want to check in multiple times but do not want a build every time we check in our code so we can have a fixed time or period in which we can initiate the build for building of the checked-in code.
The more details about these builds can be found at the below location.
Gated-check in Builds
Continuous Integration Builds
Nightly Builds
Build Process is a Process of compiling your source code for any errors using some build tools and creating builds(which are executable versions of the project). We(mainly developers) do some modifications in the source code and check-in that code for the build process to happen. After the build process it gives two results :
1. Either build PASSES and you get an executable version of your project(Build is ready).
2. It fails and you get certain errors and build is not created.
There are different types of build process like :
1. Nightly Build
2. gated Build
3. Continuous integration build etc.
Build tools help and automates the process of creating builds.
*So in Short Build is a Version of Software in pre-release format used by the Developer or Development team to gain confidence for the final result of their Product by continuously monitoring their Product and solving any issues early during the development process.*
You have been using them - IDE is a build tool. For the command line you can use things like make.
People use command line tools for things like a nightly build - so in the morning with a hangover the programmer has realised that the code that he has been fiddling with with the latest builds of the libraries does not work!
"...it is very hard to keep track of what needs to be built" - Build tools does not help with that all. You need to know what you want to build. (Quoted from Ritesh Gun's answer)
"I heard they're used almost in all kind of real-world development" - For some reason, software developers like to work in large companies. They seem to have more unclear work directives for every individual working there.
"How come I never needed them in past four years". Probably because you are a skilled programmer.
Pseudo, meta. I think build tools do not provide any really real benefit at all. It is just there to add a sense of security arising from bad company practices, lack of direction - bad software architectural leadership leading to bad actual knowledge of the project. You should never have to use build tools(for testing) in your project. To do random testing with a lack of knowledge of the software project does not give any sort of help at all.
You should never ever add something to a project without knowing it's purpose, and how it will work with the other components. Components can be functional separate, but not work together. (This is the responsibility of the software architect I assume).
What if 4-5 components are added into the project. You add a 6th component. Together with the first added component, it might screw up everything. No automatic would help to detect that.
There is no shortcut other than to think think think.
Then there is the auto download from repositories. Why would you ever want to do that? You need to know what you download, what you add to the project. How do you detect changes in versions of the repositories? You need to know. You can't "auto" anything.
What if we were to test bicycles and baby transports blindfolded with a stick and just randomly hit around with it. That seems to be the idea of build tool testing.
I'm sorry there are no shortcut
https://en.wikipedia.org/wiki/Scientific_method
and
https://en.wikipedia.org/wiki/Analysis
what's the point of using ant, maven, and buildr? won't the using build in eclipse or netbeans work fine? i'm just curious what the purpose and benefit of extended build tools are.
Dependency Management: The build tools follow a component model that provides hints on where to look for dependencies. In Eclipse / Netbeans, you have to depend on a JAR and you don't really know if this JAR has been updated or not. With these build tools, they 'know' updates in dependencies (generally because of a good integration with your source control repository), recalculate transitive dependencies and ensure that everything is always built with the latest versions.
Access Control: Java, apart from class level access control, has no higher abstraction. With these build tools you can specify exactly which projects you want to depend on you and control visibility and access at a higher level of granularity.
Custom Control: The Eclipse / Netbeans build always builds JAR files. With custom build mechanisms, you could build your own custom (company-internal) archive with extra metadata information, if you so wish.
Plugins: There are a variety of plugins that come with build tools which can do various things during build. From something basic like generating Javadocs to something more non-trivial like running tests and getting code coverage, static analysis, generation of reports, etc.
Transport: Some build systems also manage transport of archives - from a development system to a deployment or production system. So, you can configure transport routes, schedules and such.
Take a look at some continuous integration servers like CruiseControl or Hudson. Also, the features page of Maven provides some insight into what you want to know.
On top of all the other answers. The primary reason I keep my projects buildable without being forced to use NetBeans or Eclipse is that it makes it so much easier to setup automated (and continuous) builds.
It would be rather complicated (in comparison) to set up a server that somehow starts eclipse, updates the source from the repository, build it all, sends a mail with the result and copies the output to somewhere on a disk where the last 50 builds are stored.
If you are a single developer or a very small group, it can seem that a build system is just an overhead. As the number of developers increases though it quickly becomes difficult to track all changes and ensure developers are keeping in sync. A build system reduces the rate of increase of those overheads as your team grows. Consider the issues of building all the code in Eclipse once you have 100+ developers working on the project.
One compelling reason to have a separate build system is to ensure that what has been delivered to your customers is compiled from a specific version of the code checked into your SCM. This eliminates a whole class of "works on my box" issues and in my opinion this benefit is worth the effort on its own in reduced support time. Isolated builds (say on a CI server) also highlight issues in development, e.g. where partial or breaking changes have been committed, so you have a chance to catch issues early.
A build in an IDE builds whatever happens to be on the box, whereas a standalone build system will produce a reproducible build directly from the SCM. Of course this could be done within an IDE, but AFAIK only by invoking something like Ant or Maven to handle all the build steps.
Then of course there are also the direct benefits of build systems. A modular build system reduces copy-paste issues and handles dependency resolution and other build related issues. This should allow developers to focus on delivering code. Of course every new tool introduces its own issues and the learning curve involved can make it seem that a build system is a needless overhead (just Google I hate Maven to get some idea).
The problem with building from the IDE, is that there are tons of settings affecting the build. When you use a build tool all the settings a condensed in a more or less readable form into a small set of scripts or configuration files. This allows in the ideal case anybody to execute a build with hardly any manual setup.
Without the build tool it might become next to impossible to even compile your code in let's say a year, because you'll have to reverse engineer all the settings
Different features. For example Maven can scan your dependencies and go download them, and their dependencies so you don't have to. For even a medium sized project there may be a very large number of dependencies. I don't think Eclipse can do that.
#anonymous,
Why do you I assume that me, a member
of your team, is using an IDE all the
time? I might want to build the code
on a headless build server, is that
ok?
Would you also deny me the right of
using a continuous integration
engine?
May I fetch dependencies from a central repository please? How can I do that?
Would you tie me to a specific IDE? I can't run Eclipse easily on my very old laptop, but I'll buy a new one.
Maybe I should also uninstall subversion and use patches or just zip folders on a sftp/ftp/Samba share.
The build tools allow you to do a build automatically, without human invention, which is essential if you have a code base being able to build many applications (like we do).
We want to be certain that each and everyone of our applications can build correctly after any code base changes. The best way to check that is to let a computer do it automatically using a Continouos integration tool. We just check in code, and the CI server picks up there is a change and rebuilds all modules influenced by that change. If anything breaks the responsible person is mailed directly.
It is extremely handy being able to automate things.
To expand on Jens Schauder's answer, a lot of those build options end up in some sort of .project file. One of the evils of Eclipse is that they store absolute path names in all of it's project files, so you can't copy a project file from one machine to another, which might have its workspace in a different directory.
The strongest reason for me, is automated builds.
IDEs just work on a higher abstraction layer.
NetBeans nativly uses Ant as its underlying build tool and recently can directly open maven projects in NetBeans. Hence, your typical NetBeans project can be compiled with ant and your maven project already is a NetBeans project.
As with every GUI vs CLI discussion, IDEs seem easier for beginners but once you get the idea it becomes cumbersome to do complex things.
Changing the configuration with an IDE means clicking somewhere which is easy for basic things but for complex stuff you need to find the right place to click. Furthermore IDEs seem to hide the importent information. Clicking a button to add a library is easy but you may still not know where the library is, etc.
In contrast, using a CLI isn't easy to start with but becomes quickly easy. It allows to do complex things more easily.
Using Ant or Maven means that every one can choose his/her own IDE to work one the code. Telling someone to install IDE X to compile it is much more overhead than telling "run <build command> in your shell". And of course your can't explain the former to an external tool.
To sum up, the IDE uses a build tool itself. In case of NetBeans Ant (or Maven) is used so you can get all the advantages and disadvantages of those. Eclipse uses its own thing (as far as I know) but also can integrate ant scripts.
As for the build tools themselves Maven is significantly different from Ant. It can download specified dependencies up to the point of downloading a web server to run your project.
In all projects, developers will often manually invoke the Build process.but it is not Suitable for large Projects, Where it is very difficult to keep track of what needs to be built, in what sequence and what dependencies there are in the building process.Hence we Use Build Tools for Our Projects.
Build Tools Done varieties of the task in the Application which will do by the Developer in their daily life.
They are
1.Downloading dependencies.
2.Compiling source code into binary code.
3.Packaging that binary code.
4.Running tests.
5.Deployment to production systems.
I've grown disillusioned with Groovy based alternatives to Ant. AntBuilder doesn't work from within Eclipse, the Groovy plugin for Eclipse is disappointing, and Gradle just isn't ready yet.
The Ant documentation has a section titled "Using Ant Tasks Outside of Ant" which gives a teaser for how to use the Ant libraries from Java code. There's another example here:
http://www.mail-archive.com/dev#ant.apache.org/msg16310.html
In theory it seems simple enough to replace build.xml with Build.java. The Ant documentation hints at some undocumented dependencies that I'll have to discover (undocumented from the point of view of using Ant from within Java).
Given the level of disappointment with Ant scripting, I wonder why this hasn't been done before. Perhaps it has and isn't a good build system.
Has anyone tried writing build files in Java using the Ant libraries?
Our build system is primarily based upon exactly what you describe, and it works very well indeed. We use the Ant tasks (especially the file-manipulation tasks) from custom java programs which assemble the application using auto-discovery of convention-based application module layout.
You may need some glue Ant XML, to do things like compile the build scripts themselves, and to actually invoke the java to perform the build, but it's minor.
Not only is java more readable than Ant, especially when it comes to conditional execution, but it's vastly quicker. Our Ant-based build used to take a minute or so to assemble an EAR, now the java based version takes about 5 seconds.
You had a fine idea. Cliff Click had a similar idea: http://blogs.azulsystems.com/cliff/2008/01/i-hate-makefile.html
If you go through with it I advise you to keep it as simple as possible so your build system doesn't need a [non-trivial] build system itself.
Given that Java is compiled, this is kind of a chicken and egg problem. You need to build your Build.java to build your project.
Ant currently supports inline scripting using BeanShell, Groovy and a bunch of others, that can really help reduce the need for that.
EDIT: In response to Dean's multiple comments, if your build consists strictly of a long proceedure, then indeed you don't need ant's build script. However, the power of the build script is that it ensures that dependencies are only executed once while allowing for mulitiple entry points, something that is far from trivial if you roll your own.
If you don't like the XML format, you are not alone, the author of ANT agrees with you. However, if your view of the build process is something that can be launched from your IDE as its only launch point, I would say that your build needs are quite simple.
EDIT2: I upvoted skaffman's answer because it speaks directly to the question. In the comments we seem to agree that the approach is fine for a procedural build, but would not work for a declarative one, and that you need at least a little ANT xml to get the ball rolling with your Build.java to avoid the chicken and egg problem. That seems to get to the crux of the matter.
An important point seems to have gotten lost here.
Ant is written in Java and what I'm looking for is a better way to use the Ant tasks (APIs in the Ant libraries) than through xml. For the life of me I can't see how using xml to invoke Java would ever be better or easier than using Java to invoke Java.
The one obstacle is that the xml approach is documented whereas the Java approach is not documented so I'll have to download and get familiar with the Ant code.
I held back from posting this question for a couple of weeks because I was sure that someone had done this before and that my google-foo just needed improving. It just seems so obvious to use Java to call the Ant APIs instead of xml that I'm still surprised that there wasn't a parallel Java-based approach developed for Ant as well as the xml approach.
Just because it is obvious doesn't mean that someone has done it before, though.
While I suppose its possible, you would probably be better off with shell scripts then writing a full on java program to simply automate builds.
You would be missing out on one of the key uses for ant, which are the easy-to-specify filesets and easy to read in properties.
I have stuck with ant as Groovy is too close to writing an entire application to just build your real application. Too complicated for the trouble.
While using Ant tasks inside Java programs is fairly easy, I probably would stick to Ant build files if I were you. If you're doing some groovy development, if Eclipse doesn't do what you need, maybe you need to look elsewhere(IntelliJ, NetBeans, etc.).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I am trying to revamp our build process, which is currently a gigantic Ant build.xml that calls into other ant build files and executes several Java classes to perform more complex logic that would be impossible/scary to attemp in Ant.
Background:
experience in Java and Ant, some Groovy
Windows platforms
Goals:
run as a combination of command line cron and when a servlet is posted to
as simplified as possible, fewest languages and bouncing between techs
I need higher level logical power that a language like Java provides and Ant is pretty easy and we use the filtering to override default properties files for different clients. Mostly I'm wondering if there is something other than Ant/Java that people use.
Except the Ant you mentioned and the scarry make/autotools, the mainstream tools are:
SCons
Jam
CMake
Maven
I use SCons, because it is python based, well-funded and elegant.
Jam seems to be the most pragmatic one.
I don't know too much about CMake.
Maven may be the choice for you as it is Java centric and more high level than Ant.
More you can find at wikipedia: List of built tools
If you pursue Maven, then you will have two problems: a complex build and learning the f#*#ing "magic" of Maven. Maven just makes the problem worse because it is obtuse and overly-complicated.
I inherited a legacy Maven 1.x build at a large Fortune 500 company. I used Maven 2.x by choice on many other projects in recent years. I evaluated Maestro, in hopes that it might make Maven tractable. My conclusion, like many other peoples' (check the 'net), is that Maven is a big step in the wrong direction. It definitely is not an improvement over Ant.
I have used Ant for MANY years, including writing a large open-source library of Ant helper scripts. I have also extensively used its .NET cousin nAnt. However, Ant has two major failings. One, XML is simply not the right place to be doing build tasks. Two, Ant and XML do not scale well to large, complex builds. In fact, I have written a lot here at SO about my experiences in that arena (and with Maven).
Industry leaders have concluded that a build is just another application, and should be approached using general application tools. However, since it involves system-level and cross-platform functionality, most development languages/platforms are not properly suited (which includes Java, and therefore Ant and Maven). That also excludes .NET.
I spent two years looking for an alternative, and I found it: Python. It has the right combination of system-level access, cross-platform portability, simplicity, readability, power, robustness, and maturity. SCons, buildbot, setuptools/easyinstall, and base Python are my current target platform for the build process. When necessary, integration with Ant, Maven, and any other such tool is easy. Meanwhile, I can use these tools for the core of any build on any platform with any source language. No more roadblocks, no more crazy complexity, no more supposedly-helpful "declarative" scripting, no more black-box f#*#ing "magic".
If you can't switch to Python, then try Ant + Ivy (at apache.org). It gives you Maven's cool repository without most of Maven's evils. That is what I am doing as well, where necessary and suitable.
Best wishes.
Also take a look at
Gant
Gradle
While more general purpose build systems like SCons are very powerful, the Java support is somewhat limited in comparison to systems specially tailored to build Java projects.
I like using Rake as you can fall back on the power of the whole Ruby language and it's framework library when needed.
I use Ant, taking advantage of its macro feature. If you layout your project in a consistent mannner, you can eliminate a lot of the duplication by writing macros.
I've been building up an Antlib containing macros and custom tasks that I reuse across multiple projects.
Alternatively, some people swear by Maven. Other people just swear about Maven.
I use Maven, not just for build, I also use their release/dist plugin.
In a pair of commands I can have code that was in a source control to build, package and release.
The release plugin handles updating the version numbers, dist handles how to put everything together and zip it.
Ant looks hard when compared to Maven. Sure there is a learning curve with Maven, but reading a pom.xml is far easier than reading a build.xml.
Maven needs to be far less verbose.
I like Ant but only if you spend the time to write your own Java plugins to encapsulate complex actions. It isn't hard but unfortunately most people try to write their logic in XML w/the ant-contrib stuff. I think this is a huge mistake.
I've heard good things about rake and the groovy tools (mentioned in another comment) but I've got no experience with them.
If you're trying to script together several steps in a life-cycle you might be better off using a process automation based build server like AnthillPro (Cruise, BuildForge and Electric-Commander are the others in this space).
Another place to ask this kind of question is the CITCON mailing list. CITCON is a conference on Continuous Integration and Testing and the associated mailing list has turned into a really great community around these kinds of topics.
(I'm an organizer for CITCON but a labor of love not a profit maker. It really does have a really helpful mailing list. If I was pimping something for money it would be The CI Guys. ;-) )
Stick with Ant since you're building Java. I've mixed Ant/SCons for some JNI work, but in general I'd stay with Ant especially since you've got an existing build setup in Ant. Porting to Maven will be like shoving a square peg through a wall with no holes.
Embrace your custom Java logic for any and consider writing proper Ant tasks instead of executing external Java code. I solved some very complex parts of our build process by simply extending Ant to do exactly what I needed, ex. managing icon resources for a large gui project or injected subversion information directly info jar manifests (thank you SVNKit)
I'd go with Ant any day of the week.
It's not perfect; XML is very verbose and implementing any logic at all is almost impossible, but even the most junior engineer on the team can at least understand what the ant file is doing within a day.
Complex logic can be refactored using java and integrated in ant, if you so wish. Ant gives you all the power of java:)
Dependency resolution is difficult no matter what system you use. With ant, the best solutions seem to be either a lib directory in which all your jars are stored, or an internal web server from which the libraries are copied at build time.
I also have some experience with both Maven 1 and Maven 2. That experience left me with the feeling that Maven is awesome for hobby projects, but can have complications for software you need to maintain over time.
I see two important problems with Maven:
Any dependency you import using Maven may change over time without you knowing it, resulting in weird problems.
You import the licenses of not only the software you import directly using Maven, but also the licenses used by the libraries which are indirectly imported
In short, I dislike the fact that the build depends on the time it is started. That can be a true problem when producing a bugfix release a year after the production release.
These problems can of course be managed (maybe using a nexus proxy) but you need to consider them before rebuilding the build system. At my company we decided to use Ant for all new project and try to port maven 1 and 2 to ant whenever the occasion presents itself. It's just too difficult to keep it working.
My advice, if you and your team know how to deal with ant, try to refactor your ant file and don't jump on some other build tool. It just takes too much time to get it right; time you could spend making money and surviving as a company :)
I use Rake everywhere I can. Where you need to build java code you might use it with jruby, or look at something like: buildr
We use luntbuild. It's a web app that's very easy to use. It will check out from CVS/SVN, automatically increment the version/build number, execute build tasks in ant scripts and tag your repository with the new version. Can schedule automatic builds, have it email you or contact you via IM, also has security and build dependencies.
We're still using version 1.2.3 but I see it's up to 1.6.0. It just works.
http://luntbuild.javaforge.com/
EDIT: Re-reading your question I see now that you're looking for something to replace Ant. In our case Ant is not really a problem. We have projects setup in Netbeans, which uses Ant for building and we just have to implement some hooks into the existing scripts provided by Netbeans which is very easy to do.
EDIT: Looks like you can call Ant from Groovy. That would be nice because then you can re-use all the tasks that already exist for Ant.
http://groovy.codehaus.org/Using+Ant+from+Groovy
Try FinalBuilder
It provides a GUI interface to whatever your build process may be and has a native action for almost everything, plus an action studio where you can create your own.
With a bit of planning can be very streamlined.
I have to add to these one solution that I find I can't live without ... its called Hudson. It only takes a few seconds to setup and you can usually get away with most of whatever your existing ANT files are already doing.
Additionally, Hudson provides a great way to "cron" builds, execute test cases, and generate "artifacts" (e.g. build products) in a way that anyone can download.
It is hard to capture all that it can do for you ... so just try it out ... you will no be disappointed.
Maven is really good choice to do large builds...in the majority of the cases where it doesn't work is very simple. The people misunderstand the concepts of Maven. If your are working with the "maven way" you will end up with smaller modules which gives you a better architecture in your software. On the other hand things like Hudson will support you in reducing build times by using Maven, cause Hudson supports to build only changed modules which is not supported by any other build tool. The problem with Maven is to learn and understand the concepts of Maven for example the structure of a project(folders etc.) or only a single artifact etc. The build-cycle will support you in different areas: compiling, packaging, deployment and release which is not supported by other tools (only if you implement it by hand...I've wrote many large Ant scripts to reach this)...Other problem like changes over the time are caused by ignoring the best practice and pin pointing versions which are used.
I use mainly Ant, but Maven is also a good tool. With ant you can do anything you want.
At our company, we created a general purpose ant builder that does a lot of things: Build, Compess images, minify, generate documentation, pack files.. It is open source and we are open to improvements. You can get it here:
https://github.com/edertone/TurboBuilder