I think it would be nice if some repository of standard Ant scripts was created accompanied by repository of custom tasks.

It we have such repo then typical Ant files would be one-liners

Welcome to Apache MAVEN :) http://maven.apache.org/guides/getting-started/index.html In addition to possibility of using ANT tasks and many other things it also can produce ANT build scripts using Maven 2 Ant Plugin http://maven.apache.org/plugins/maven-ant-plugin Other core plugins - http://maven.apache.org/plugins/index.html

Do you really suppose I am so ignorant that I do not know about Maven? That is insulting. Maven has good ideas behind but their implementation is far from being usable IMO ( well what could I expect from author of Jelly ;) ). In general Maven feels a lot like M$ thingies: easy to get started - but hard to progress, difficult to get things the way I want them to be, even reasonable things, plus unpredictable breaks and version hypersesnsitivity. It feels "wizardish" if you will. Another huge red flag: build content, possibility and repeatability depends on repository content. That is because of ranges in the dependency version definitions and plugins. It means that if new version was uploaded to repository - I can not repeat my week ago's build the way it was done a week ago. That is why I prefer Ant - it makes things more traceable and obvious - all we need IMO is to create a little bit of convenience around it: repository of standard build scripts and custom tasks.

Do you really suppose I am so ignorant that I do not know about Maven? That is insulting.

Come on, we're discussing build tools only not your or someone else personality - I'm not supposing anything like that or even think about that. Lets move to the topic.

Maven has good ideas behind but their implementation is far from being usable IMO

As you've said - IYO. I find it personally saving time and reducing maintenance nightmare when you have dozens of "build.xml" files and "lib" dirs. And many projects at Apache found that too.

( well what could I expect from author of Jelly ;) ).

What's wrong with Jelly? You're having too many problems with tools and libs ;) Perhaps it wasn't that good idea for developing Maven 1 plugins using Jelly, but the tool alone is powerful and simple XML based scripting and processing engine.

difficult to get things the way I want them to be

Maven brings standartization to the project directory, repository of artifacts, naming of goals/tarject/phases. Most of the software project information is specified in the single XML file, and easy to reuse by plugins. If you want quite opposite things - like having your own project directory structure, your own build process, your own repository of artifacts - and all of these for EVERY project - then good like managing it, and probably you don't need Maven for that.

Another huge red flag: build content, possibility and repeatability depends on repository content. That is because of ranges in the dependency version definitions and plugins.

Lets take a look on very popular Spring framework, release 2.0 (October 2006) that uses ANT: .... lib (contains all third-party libraries needed for running the samples and/or building the framework) |--jakarta-commons ... commons-collections.jar commons-digester.jar commons-io.jar commons-httpclient.jar ... What versions jakarta-commons libs used to build the project? Ohhhh, this ANT build system totally depends on "LIB" content ;) In the strict SCM environments that is very important to have exact knowledge of what 3rd party lib version used. While I can go to the lib's origin site and compare file sizes and other things - I don't have a luxury of such time spent on such obvious things ;) Maven takes declarative approach and uses information from the POM to make your local repository in synch with your intranet (or remote public) repository.

It means that if new version was uploaded to repository - I can not repeat my week ago's build the way it was done a week ago.

Wrong! Instead of "SNAPHOT" versions you need to include required versions to the tag for your dependencies.

That is why I prefer Ant - it makes things more traceable and obvious

IMO, it's quite opposite - MAVEN brings it declaratively withing single POM (Project Object Model) file. ANT is brilliant build tool but once someone played enough with LEGO style of build, someone will want standartization - like project directory structure, repositories of artifacts, standart goals and lifecycles like compile-test-package-...

all we need IMO is to create a little bit of convenience around it: repository of standard build scripts and custom tasks

That's what I'm talking about ;) - MAVEN already provides it out of box - and I don't need to spend my time designing/creating these "standard build scripts and custom tasks" - they are widely accepted and available and I don't have a "Not Invented Here (NIH)" disease ;) http://en.wikipedia.org/wiki/Not_Invented_Here Maven can call any ANT task if needed - so no previous efforts are lost. Or even more - MAVEN can generate ANT script from POM or Eclipse project files.

Another huge red flag: build content, possibility and repeatability depends on repository content. That is because of ranges in the dependency version definitions and plugins.

It means that if new version was uploaded to repository - I can not repeat my week ago's build the way it was done a week ago.

You only get this kind of behaviour if you're relying solely on uncontrolled repositories (eg. the various public repositories). If you configure your own repository (perhaps with the support of a tool like m2proxy or Artifactory) and pay some attention to what goes into it, then you won't have these problems. It's a shame that this misconception has somehow become entrenched in the minds of the uninitiated / ill-informed. I've found Maven to provide pretty compelling productivity improvements over other Java build systems, but the widely held negative perception of it makes it a tough sell. Cheers, Peter

Another huge red flag: build content, possibility and repeatability depends on repository content. That is because of ranges in the dependency version definitions and plugins.

It means that if new version was uploaded to repository - I can not repeat my week ago's build the way it was done a week ago.

You only get this kind of behaviour if you're relying solely on uncontrolled repositories (eg. the various public repositories). If you configure your own repository (perhaps with the support of a tool like m2proxy or Artifactory) and pay some attention to what goes into it, then you won't have these problems.

May I suggest specifying version numbers? That's a much easier solution. Configuring your own repositories is a good option if you're worried about someone changing the contents of a library and a version without incrementing the version number. However, I've been using maven2 for over a year and have never experienced issues with repeatability of builds. Have you actually experienced this issue Konstantin? I'm very surprised that you claim issues in repeatability of builds and that maven2 is very Microsoft-like. I don't wish to "insult" you as the previous poster did, but from those two claims alone, I'd wonder if you and I were even talking about the same tool. My experience on using it in production for an enterprise project has been that maven is indispensable for it's dependency management alone. The more your project depends on open source components, the more you need a way of managing all the shared dependencies that crop up when you use hibernate, jsf, spring, etc. I also like that it's standardized project layout and can create WTP projects. It is a huge timesaver and it's dependency management is a major safety net for my projects. To put things in perspective, I recently worked on a 20 developer project (which I consider to be very large). Every developer took over 4 hours to setup and build the project for the first time...after installing & configuring the JDK, database, eclipse, etc. With maven2, the process consists of the following: 1. download code from source control 2. run "mvn eclipse:eclipse" 3. import the project created 4. start coding. Your project has been created for you and all libraries have been setup. That was almost as easy as using Grails. : ) After using maven2, and reviewing schmant's examples, I don't yet see any compelling reason to use schmant. I'm sure this will be valuable to someone, but maven2 is just too hard to beat. I've written many ANT scripts in the past, but I don't think I'll be writing any in the future thanks to maven.

May I suggest specifying version numbers?....

That is right way to do, but half of the solution IMO :) There should be standard ways of getting to know if update is available, trying the version etc.

Have you actually experienced this issue Konstantin? I'm very surprised that you claim issues in repeatability of builds and that maven2 is very Microsoft-like.

Those are two different issues: unrepeatability of builds ( when versions are specified as ranges ) and Wizard-like (MS-style) feel of Maven. Yes, I did experience unrepeatability of builds because dependencies versions were specified as ranges like (1.0,). Any system that uses this type of version definitions, it is not specific to Maven, but it looks like encouraged and widely used practice. That is pragmatic way of simplifying dependencies management but it bites from time to time. Because the same kind of version definitions is applied to Maven plugins - they bite too. On wizardish feel - Ant might be verbose but it easy to track why things happen in a certain way and change to someone liking, Maven is different - it works nicely when it works but if it doesn't then it is really hard to figure out what goes wrong and how to fix it.

Yes, I did experience unrepeatability of builds because dependencies versions were specified as ranges like (1.0,)... it looks like encouraged and widely used practice. That is pragmatic way of simplifying dependencies management but it bites from time to time.

The versioning issue is actually not related to Maven - the same thing may happen with any build system including ANT. Maven doesn't encourages using version ranges, however it supports it. It is responsibility of a developer to make sure that the build is reproducable - see also http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution

Ant might be verbose but it easy to track why things happen in a certain way and change to someone liking, Maven is different - it works nicely when it works but if it doesn't then it is really hard to figure out what goes wrong and how to fix it.

Maven has similar to ANT built-in support for producing extended output using command-line options plus supports help plugin: Command-line options: -X,--debug Produce execution debug output -e,--errors Produce execution error messages Maven Help Plugin(http://maven.apache.org/plugins/maven-help-plugin): mvn help:effective-pom displays the effective POM for the current build, with the active profiles factored in. help:active-profiles lists the profiles which are currently active for the build. help:effective-settings prints out the calculated settings for the project, given any profile enhancement and the inheritance of the global settings into the user-level settings.

The versioning issue is actually not related to Maven - the same thing may happen with any build system including ANT.

Did not I say the same? (Ant does not have dependencies management on its own) However

Maven doesn't encourages using version ranges, however it supports it.

It does use ranges and thus endorses and encourages them. And it (and other tools) does not provide any sane alternative for version management and updates. Since Maven does not help with robust dependencies management I personally prefer Ant+Ivy, not ideal, but in the end is more robust and manageable than Maven. That may change in the future....

Did not I say the same? (Ant does not have dependencies management on its own)

Yes but custom task can do it - such as Antlib for Maven 2.0

It does use ranges and thus endorses and encourages them.

I'm afraid, I disagree. There is big difference between "supports version ranges" and "encourages using them" Neigher Maven runtime nor its documentation does NOT encourages using version ranges. Please provide any examples from http://maven.apache.org that show opposite. If developer decides to use version ranges - it is developer responsibility to understand all consequences of such decision (such as mismatches between facade interfaces).

Since Maven does not help with robust dependencies management ...

I'm sorry that you feel that way but it's just IYO

Yes but custom task can do it - such as Antlib for Maven 2.0

This particular library is creation of Maven folks and carry all the same baggage...

Neigher Maven runtime nor its documentation does NOT encourages using version ranges. Please provide any examples from http://maven.apache.org that show opposite.

http://maven.apache.org/ref/2.0.4/maven-model/maven.html ranges are not discouraged and Maven does not provide any alternative for version management, but should IMO, as any other dependencies managers should.

http://maven.apache.org/ref/2.0.4/maven-model/maven.html
ranges are not discouraged and Maven does not provide any alternative for version management, but should IMO, as any other dependencies managers should.

From the reference you've mentioned: dependency version The version of the dependency, e.g. 3.2.1. In Maven 2, this can also be specified as a range of versions. plugin The version (or valid range of verisons) of the plugin to be used. I'm not sure where you've found encouragement to use range of versions. Alternative and best pracitice is blady simple - use EXPLICIT versions of artifacts in dependencies. It is the same as within ANT (lib dir). If you're decided to use transitive way - that fine - but don't blame Maven for that.

ant schmant... i use javac ;-)

Mr. Inguva, can you please explain your statement? I'm willing to bet you use to work for a company that used VSS. Best regards, Richard L. Burton III

This article, at least until it starts talking about macros, is quite relevant to this. Lisp makes me wonder why XML was invented, and why almost every other programming language ever was invented. Then I remember the power of marketing. Anyway, here's the article: http://www.defmacro.org/ramblings/lisp.html (scroll down to Ant Reloaded if you're impatient - hell, if you're impatient, just don't bother doing anything. You know where the power button is).

... Lisp makes me wonder why XML was invented, and why almost every other programming language ever was invented. Then I remember the power of marketing.

That's what LISP people think. Everyone else thinks it's the power of the market. :-)

... Lisp makes me wonder why XML was invented, and why almost every other programming language ever was invented. Then I remember the power of marketing.

That's what LISP people think. Everyone else thinks it's the power of the market. :-)

Others think that it is power of ignorance and product of education by "ZZZZ For Dummies in 24 hours" series of books.

That's what LISP people think.

Thanks for the compliment.

Ant provides support for scripting already. See http://ant.apache.org/manual/OptionalTasks/script.html. This mechanism allows any target to be implemented in a number of scripting languages, including JavaScript. You then have access to all ant tasks, built in or otherwise. It also supports JVMs prior to 1.6. Here is an example from the docs: <!--?xml version="1.0" encoding="ISO-8859-1"?--> <script language="javascript"> <![CDATA[ // import statements // importPackage(java.io); importClass(java.io.File); // Access to Ant-Properties by their names dir = project.getProperty("fs.dir"); includes = MyProject.getProperty("fs.includes"); excludes = self.getProject() .getProperty("fs.excludes"); // Create a <fileset dir="" includes=""/> fs = project.createDataType("fileset"); fs.setDir( new File(dir) ); fs.setIncludes(includes); fs.setExcludes(excludes); // Get the files (array) of that fileset ds = fs.getDirectoryScanner(project); srcFiles = ds.getIncludedFiles(); // iterate over that array for (i=0; i<srcFiles.length; i++) { // get the values via Java API var basedir = fs.getDir(project); var filename = srcFiles[i]; var file = new File(basedir, filename); var size = file.length(); // create and use a Task via Ant API echo = MyProject.createTask("echo"); echo.setMessage(filename + ": " + size + " byte"); echo.perform(); } ]]></script>

What the Java community didn't need was another build tool. Ant has a lot of momentum and is supported in many IDEs already. Why do we need another one? The better alternative would be for a team to offer tasks that can be used in Ant to supply features they think are missing. I wish more people in the Java community would see how this type of fragmentation is BAD for the community as a whole. If I was a n00b, this just would be one more tool that I would have to spend time evaluating and documenting. One more frustration. One more reason to throw my hands up and say, "To heck with this, I'll use something where every time I turn around I don't have to evaluate 10 alternatives for doing the same thing..." (read: *choose* vendor lock-in) For the love of the Java community and all other things, integrate with or work on what's already there.

What the Java community didn't need was another build tool. Ant has a lot of momentum and is supported in many IDEs already. Why do we need another one? The better alternative would be for a team to offer tasks that can be used in Ant to supply features they think are missing.

I wish more people in the Java community would see how this type of fragmentation is BAD for the community as a whole. If I was a n00b, this just would be one more tool that I would have to spend time evaluating and documenting.

One more frustration.

I agree. Why would anyone want to try and innovate? We already have Ant and Maven and we'll never need anything different. Pick the one you like. We don't want to have to choose anything else. I can't believe anyone would even try to do anything new. Obviously new and different ways of doing things are so bad Bad BAD!

I agree. Why would anyone want to try and innovate? We already have Ant and Maven and we'll never need anything different. Pick the one you like. We don't want to have to choose anything else. I can't believe anyone would even try to do anything new. Obviously new and different ways of doing things are so bad Bad BAD!

How is this innovative at all? As Andrew O'Malley pointed out, Ant already has support for scripting, whereas Schmant seems to have a dependency on Java 6. I don't see the usefulness of this build tool. Well, at least it's not another web framework.

How is this innovative at all? As Andrew O'Malley pointed out, Ant already has support for scripting, whereas Schmant seems to have a dependency on Java 6.

Yes, and you can turn a car into an aeroplane by bolting on a pair of wings. The reason for me to build Schmant was that I could not make Ant do what I wanted it to. I probably could have tried harder, but it was not the first time that I had that problem. Before, I always ended up turning myself inside out just to create a solution that never failed to feel ... wrong. This time around, I wanted to do something different.
Schmant's dependency on Java 6 is a runtime dependency. You can build code for any old Java that you like. You could even use it to compile C code if you wanted to (and was prepared to implement a couple of tasks too).

I don't see the usefulness of this build tool. Well, at least it's not another web framework.

Then don't use it...

I don't see the usefulness of this build tool. Well, at least it's not another web framework.

Then don't use it...

If you are not interested in people using your tool then do not publish your code and do not advertise it. Otherwise please be prepared to to explain your reasons over and over again. And especially in case of offering a total replacement for something that works reasonably well.

I agree. Why would anyone want to try and innovate?

That is not at all what I said or meant. I didn't say that innovation was a bad thing ("fragmentation" != "innovation"). I feel quite the contrary.

We already have Ant and Maven and we'll never need anything different. Pick the one you like. We don't want to have to choose anything else.

So for the sake of what you call "innovation" we can't work on those projects to submit our own improvements? I fail to see how improving existing things can't be innovative.

I can't believe anyone would even try to do anything new. Obviously new and different ways of doing things are so bad Bad BAD!

So why even use Java? Why use HTML? Why use a web browser? They're not new, so surely you can write different implementations of these yourself. Is that what you need to do to be good? Is that what innovation means?

What the Java community didn't need was another build tool. Ant has a lot of momentum and is supported in many IDEs already. Why do we need another one? The better alternative would be for a team to offer tasks that can be used in Ant to supply features they think are missing.

I wish more people in the Java community would see how this type of fragmentation is BAD for the community as a whole. If I was a n00b, this just would be one more tool that I would have to spend time evaluating and documenting.

One more frustration.

One more reason to throw my hands up and say, "To heck with this, I'll use something where every time I turn around I don't have to evaluate 10 alternatives for doing the same thing..." (read: *choose* vendor lock-in)

For the love of the Java community and all other things, integrate with or work on what's already there.

I completely disagree with this all too common sentiment. There are "too many" choices and "fragementation." No, there are difficult problems to solve and different people address them in different ways. Having choices is not a bad thing. Sure it means you have to make an informed decision about what to use sometimes, but that is not bad either. This is the same rant as there are "too many Linux distros" and so on. Some flavors are better than others, some address different areas of concern, some people may want to go a completely different direction. There are *also* people contributing to Ant, having *both* is not bad. Artificial selection will cause some projects to rise to the top, and others to wane, based on the overall merits. Saying "work on what's already there" is oversimplified, and the whole throw my hands up and "choose vendor lock in" is just laziness (which will bite you later, one way or another). (And don't get me wrong, sometimes the approaches of two projects are NOT all that different, and it would make more sense to merge them. Having separate projects just because of political or personality issues, or lack of communication, is bad. But having fewer projects just because of "too many choices" is also bad. Schmant, though I have not looked into it, does not sound like it falls into the duplicate category at all - even though it is addressing the same problem domain.)

What the Java community didn't need was another build tool. Ant has a lot of momentum and is supported in many IDEs already. Why do we need another one? The better alternative would be for a team to offer tasks that can be used in Ant to supply features they think are missing.

I wish more people in the Java community would see how this type of fragmentation is BAD for the community as a whole. If I was a n00b, this just would be one more tool that I would have to spend time evaluating and documenting.

One more frustration.

One more reason to throw my hands up and say, "To heck with this, I'll use something where every time I turn around I don't have to evaluate 10 alternatives for doing the same thing..." (read: *choose* vendor lock-in)

For the love of the Java community and all other things, integrate with or work on what's already there.

+1 Why another one?

1. Do not be dependent on Javax-scripting - it's only Java 6 solution. 2. Pick any scripting language engine (e.g. js.jar), add your libraries (schmant.jar, entityfs.jar) and use it from schmant.bat. Or even better put ant.jar and the rest of requied libraries on CLASSPATH and use it from schmant.bat. Ant has some API which could be invoked from JS or BSH or Groovy etc. in same way as your API. Like this (in beanshell): String repositoryHome = System.getProperty("repository.home"); addClassPath(repositoryHome + "/org/apache/ant/ant/1.7.0/ant-1.7.0.jar"); addClassPath(repositoryHome + "/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar"); // run-ant.bsh import org.apache.tools.ant.Project; import org.apache.tools.ant.ProjectHelper; import org.apache.tools.ant.BuildLogger; import org.apache.tools.ant.DefaultLogger; Project project = new Project(); project.init(); BuildLogger logger = new DefaultLogger(); logger.setMessageOutputLevel(Project.MSG_INFO); logger.setOutputPrintStream(System.out); logger.setErrorPrintStream(System.err); project.addBuildListener(logger); File buildFile = new File("build.xml"); ProjectHelper.getProjectHelper().parse(project, buildFile); project.executeTarget(project.getDefaultTarget()); 3. Use groovy ant builder, like this: // build.groovy /* <?xml version="1.0"?> */ class Build { def ant = new AntBuilder() def base_dir = "./" def src_dir = base_dir + "src" def lib_dir = base_dir + "lib" def build_dir = base_dir + "classes" def dist_dir = base_dir + "dist" def file_name = "whoami" def classpath; Build() { ant.mkdir(dir: "${lib_dir}") classpath = ant.path { fileset(dir: "${lib_dir}"){ include(name: "*.jar") } pathelement(path: "${build_dir}") } } void clean() { delete(dir: "${build_dir}") delete(dir: "${dist_dir}") } void build() { ant.mkdir(dir: "${lib_dir}") ant.mkdir(dir: "${src_dir}") ant.mkdir(dir: "${build_dir}") ant.javac(destdir: "${build_dir}", srcdir: "${src_dir}", classpath: "${classpath}") } void jar() { clean() build() ant.mkdir(dir: "${dist_dir}") ant.jar(destfile: "${dist_dir}/${file_name}.jar", basedir: "${build_dir}") } void run(args) { if ( args.size() > 0 ) { invokeMethod(args[0], null ) } else { build() } } static void main(args) { def b = new Build() b.run(args) } } best regards, Alexander Shvets.

A complicated solution for Groovy addicts only! The ant scripting is not limited to java6. It is using the java6 scripting and Apache BSF for prior jdks

Look at Virtual Ant, way more intuitive and way easier to use. http://www.placidsystems.com/virtualant/

I think a build tool is the perfect place for a clearly define d DSL. Allowing any and all languages to participate in a build is probably not a good move.

Ant is doing really good and is extendable, i think there is really no need of a new build tool. Its not that WE DONT NEED but ant is more preferrable among the developers due to its manageability using xml and properties files. It is easy enough to read and its platform independent, so i dont think we need a new build tool for any reason, except for another option. May be you can spice up this tool for some more interactive and broad use.