Quokka is an open source software build system, focusing on reproducible, modular builds with fine-grained dependency management. Quokka is implemented using Java and initially focuses on supporting Java-based projects and tools. For Java developers, Quokka provides an Ant-based alternative to Maven. For Maven users, see the Side by Side Comparison for building a web application and the Quokka vs Maven Guide. Key features include: Modular Builds: Build tasks such as compilation, or source code formatting are packaged into plugins. Each project can be tailored to include specific plugins as required. Build configurations (including plugins, dependencies and other resources) can be bundled into a dependency set for re-use amongst projects. Projects can include any number of such dependency sets, and sets may nest other sets within them, providing varying degrees of reuse. Fine-grained Dependency Management: Quokka allows any number of paths of dependencies to be defined for use within a project. Selected paths can also be exported to the repository for reuse within other projects. If your project depends on another project, Quokka can automatically include its dependencies recursively. In such cases you have full control down to any level as to which dependencies are included using Path Specifications. Extensibility: Ad hoc targets can be added using standard Ant files. Alternatively, ad hoc targets may be written in a variety of scripting languages via the Script plugin Reproducible Builds: Quokka uses bootstrapping, a versioned global repository, explicit plugin and dependency versions, and a Release plugin to ensure that builds are reproducible. i.e. Building a 6 month old branch from version control today will result in exactly the same build as when it was intially checked in. Comprehensive Help: Quokka provides detailed help reports that show the full structure of a project. Furthermore, help is bundled inside all plugins ensuring users always have help available for the correct plugin version. e.g. Jetty plugin help. Finally there's the comprehensive Getting Started and User guides. For futher information, see the Quokka web site.

I scaned the Quokka vs Maven - Side by Side,but it's seems no any useful new feature than the maven2,I think it's just another 'ant+ivy',Compare with 'ant+ivy',maybe the advantage is less xml config code. Quokka's dependency config: ............ maven's dependency config: junit junit 3.8.1 test log4j log4j 1.2.14 ............. It's looks like the maven use more code,but exactly they are same config.Maybe maven shoud conside to add attribute support for all xml node to reduce the looks like 'large' code. Indeed,it's different build philosophy in maven and Quokka or 'ant+ivy',I think we shouldn't make another wheel. HUMM,IMHO,do our best to make maven more useful,simple and powerful is more sensible choice before inventing another different philosophy and more powerful build tool. Thanks.

It's looks like the maven use more code,but exactly they are same config.Maybe maven shoud conside to add attribute support for all xml node to reduce the looks like 'large' code.

You might be interested in the following: http://www.oreillynet.com/onjava/blog/2008/02/changing_the_maven_pom.html http://jira.codehaus.org/browse/MNG-3397

You might be interested in the following:

http://www.oreillynet.com/onjava/blog/2008/02/changing_the_maven_pom.html

http://jira.codehaus.org/browse/MNG-3397

Thanks for you provided resource,I will vote this. Regards.

I scaned the Quokka vs Maven - Side by Side,but it's seems no any useful new feature than the maven2,I think it's just another 'ant+ivy',Compare with 'ant+ivy',maybe the advantage is less xml config code.
Quokka's dependency config:



............


maven's dependency config:


junit
junit
3.8.1
test


log4j
log4j
1.2.14

.............



It's looks like the maven use more code,but exactly they are same config.Maybe maven shoud conside to add attribute support for all xml node to reduce the looks like 'large' code.

Indeed,it's different build philosophy in maven and Quokka or 'ant+ivy',I think we shouldn't make another wheel. HUMM,IMHO,do our best to make maven more useful,simple and powerful is more
sensible choice before inventing another different philosophy and more powerful build tool.

Thanks.

Looking at the example, having the ability to set the path for a dependency is more flexible than the maven approach. then again I never liked maven repository and how it manages libraries. peter

I scaned the Quokka vs Maven - Side by Side,but it's seems no any useful new feature than the maven2,I think it's just another 'ant+ivy',Compare with 'ant+ivy',maybe the advantage is less xml config code.

Quokka is indeed very similar to Maven at a high level. Both are largely declarative build frameworks that offer extensions via plugins. For the Side by Side example, the differences can be subtle. For example, in Maven if you forget to add the version of the Jetty plugin dependency, your build is no longer reproducible. Or the fact that paths are not fixed, allowing the additon of a 'war' path in Quokka where it made sense to do so. Another subtle difference is the number of dependencies required for the build - 116 .jar files for Maven versus 26 for Quokka (see here). So while there are are few new "features", there are many significant differences. The key feature after all is to build the web application. Ivy provides dependency management for Ant. However, it does not provide facilities to reuse build configurations (plugins and dependency sets in Quokka; plugins and pom inheritance in Maven).

I think we shouldn't make another wheel. HUMM,IMHO,do our best to make maven more useful,simple and powerful is more sensible choice before inventing another different philosophy and more powerful build tool.

Thanks.

Unfortunately, there are core design aspects of Maven that are difficult or impossible to improve incrementally. For example, the Maven repository layout and project definitions are tied together; site generation and build definitions are merged; conflict resolution touches ultimately unused dependencies; the repository is not validated for missing/inconsistent metadata, etc. Hence, another wheel.

you should educate yourself before commenting ...

Apologies, but I'm not sure to what you are referring to. When I refer to Quokka's paths not being fixed, I mean that plugins (or the project) can define arbitrary project paths and then assign dependencies to them. e.g. The following defines a path of docbook and then assigns some dependencies to it.

This is exactly the same mechanism as assigning a dependency to the compile path, except that the compile path is automatically defined by the life cycle plugin for you. The equivalent in Maven is to set the scope of a dependency.

xmlcat docbook-dtd-4-5 0.1.1 ?

To my knowledge, the scope is limited to a set of pre-defined values such as compile, test and runtime and then paths are derived using the rules defined here. This is what I meant by "fixed". I know that dependencies can be added to plugin configuration sections to form arbitrary paths, but I am not aware of any Maven functionality equivalent to defining a custom scope and assigning dependencies to it. Can you please clarify what you mean? (And educate me if necessary)

Apologies, but I'm not sure to what you are referring to. AFAIK, system does the job in Maven.

thank you for doing the research for him .... ;-)

For the record, Maven's system scope is in no way equivalent to what I described. In Quokka, you can create arbitrary paths and assign dependencies to them from the repository. Maven's system scope is designed to add libraries from the local file system that are NOT in the repository. Furthermore, the system scope is not a path at all, it just adds the declared dependency to the compile and test paths. The two concepts are not remotely equivalent.

Another subtle difference is the number of dependencies required for the build - 116 .jar files for Maven versus 26 for Quokka (see here).

It's seems the transitive dependencies conflict of maven to get the 116 .jar. Exactly the transitive dependencies conflict of maven is annoying. "Quokka provides an Ant-based alternative to Maven",it's seems great.but maven can do all things that ant did.I think the defect of maven is the transitive dependencies conflict,but that can be resolved by exclusions configuration.Besides ,the paths of quokka is indeed very flexible but I think the more flexible the more complex, and ivy provides similar path which names 'conf' if I remember correct.But maven obey the principle of 'convention over configuration',I think the 'runtime ','compile' and 'system' etc is enough. As yet,I am working well with maven. Of course ,Quokka is a very great build tools,but unfortunately,it's seems a little late to coming,after all,many project had moved to maven or created base on maven. Anyway,I would like to try quokka as soon as I can. Thanks Regards.

But maven obey the principle of 'convention over configuration',I think the 'runtime ','compile' and 'system' etc is enough.

Quokka also obeys the principle of 'convention over configuration'. The 'compile', 'test' and 'runtime' paths are all defined by default (by the life cycle plugin) and when including transitive dependencies, it defaults to taking them from the 'runtime' path. However, paths are an extremely useful thing beyond compilation and testing. e.g. Quokka's XML plugin allows you to specify the transformation factory and XML catalogs via paths. The Script plugin lets you specify a classpath for the script via a path. The Jar Bundle plugin lets you merge a set of .jar files via a path. Quokka makes configuring these paths uniform regardless of whether it's for compilation or some other purpose.

Anyway,I would like to try quokka as soon as I can.

Thanks very much - if you have any issues, please contact me on the mailing list and I'll be happy to help.

Ok,thanks for your explaination.it's worth to research,I'm also interest in build tools. :-)

Reusing build modules in ant is actually rather easy. It does require a custom Ant task. All it takes is to implement a task with something like the following syntax (i'll use the one in ant-contrib as an example): This task basically does: 1. Resolve ivy dependency inline for the mentioned artifact. Note that you could easily use maven dependency resolution instead. 2. Extract the resultant jar/zip file to a directory in the cache 3. Import a specified resource (defaults to build.xml) Once you have the task to do this, your build.xml file becomes very simple, and you now have a re-usable build module. It now becomes very easy to use a common project structure, and common build instructions. Even overriding default behavior is really easy (assume the common build module's project name is "common": ...

Thanks, really a nice tool. Before that i was waiting for maven 2.1 (the first time i heard about maven 2.1 was 4 or 5 years ago). Now i'm waiting the 1.0 of quokka. Thanks a lot. Giovanni

Thanks for the feedback Giovanni, it's much appreciated.

Now i'm waiting the 1.0 of quokka.

This is a chicken and egg problem for me. I consider the Quokka core to be essentially complete. The only thing stopping me from rolling it over to 1.0 is the lack of validation from the developer community. However, if the community is waiting for a 1.0 version number before evaluating Quokka, you can see the problem ... ;-) Also, Quokka's bootstrapping mechanism is designed to allow Quokka to evolve in the early stages without forcing users to juggle Quokka versions. Essentially bootstrapping allows multiple Quokka versions to be installed in the in the same directory structure (you just merge the lib directories of the Quokka versions). You then specify the Quokka version in the bootstrap element of build-quokka.xml and the correct version of Quokka for the particular project is forked automatically.

This is really a good job. It uses same principes and some concepts I have implemented in el4ant http://el4ant.sourceforge.net/

This is really a good job.
It uses same principes and some concepts I have implemented in el4ant http://el4ant.sourceforge.net/

Thanks Yves. I confess that I didn't come across your project when starting down the Quokka path. However, I'm in complete agreement that Ant makes a very solid base for build tools in the JVM space.