the problem with a declarative model is that it is limited to only what the designers of the model thought of (otherwise, why do we have languages at all?). this is very nice as long as you do standard things. but the minute you don't, it is very hard to "declare" what you want to be done. ask anyone that tried to use the 'assembly' plugin for an existing assembly structure (that is, didn't follow maven's).

also, what is 'declerative' anyway? in buildr, to define a project, i write:
define 'foo' do
  compile.with :log4j
  package :jar
end

is this not declerative? would writing it as:
<define name="foo">
   <compile>
       <dependency>log4j</dependency>
   </compile>
   <package type="jar/>
</define>

make it suddanly into declerative definition?

the point is that using a real language you can create declerative constructs (meaning no definition of methods, objects, loops, conditions), but still, when you need the power of a real language, you have it at your fingertips.

and a complex build requires the constructs of a real language as much as any other software module. there's no escaping it.

maven plugins are indeed written in java, but their configuration is created in xml. and it is hard to access the configuration of other plugins, or of the container. in buildr, you simply call methods with arguments and since ruby is such a great language for fluent api, all works well.

i have tried creating a build for a multi module project using maven. it was very hard. since i wanted standartization, i needed to inherit from parent poms. but if i wanted some modifications for child projects, then this became very tricky (trying to override an inherited list). also the lack of true variables, not to mention lists or hashes was a nightmare. lack of 'if' was another horror story (in maven, if you want to slightly change behavior based on a cli argument then if it is a change in a single place you need to force the user to use a property name and if it requires changing several places it means making the user use profiles. both options not intuitive for the user, not easy to code, and cannot be added to 'help').

switching to buildr was a blessing, i could abstract any complex information structure into a method/class, use a real language and create an intuitive usage for users. also, buildr, being built on rake means things are done via tasks dependencies and not hardcoded lifecycle, which means you do only what is needed.

configuration can be done via objects as well. in buildr, 'compile.sources' will return the list of sources to be compiled, 'compile.dependencies' will return the list of dependencies, etc. (it is just a matter of writing the proper accessors, very easy in ruby)

now consider a case where a module has some common sources and then a directory for jdk14 sources and a directory for jdk15 sources. in maven you can either use profiles to add the right directory, which is very verbose and not modular (the change is not local to where the sources are defined) or you need to split the module to 3 (and then run into the same issue to decide which module to choose for compilation dependencies).

in buildr, it's a simple condition. 

<pre>what needs to occur is the configuration of a build system needs to be 100% independent of the build system. the configuration should in turn be represented as a model that can be extended, along with methods to operate on that model. with this approach, whether it be  build system X, or any other process that needs access to this model can easily access and modify it.

now, should configuration (that which the human uses to describe the build configuration) be done in XML, or should it be a DSL that provides the ability to describe the configuration using a combination of declarative statements and full featured language, as in Ruby or Scala.

personally after setting up build environments since the mid-80's. i believe the best answer is using a combination of declarative statements and full featured language, as in Ruby or Scala.

why? for me, because the limitations the authors of build solutions , especially maven are much to restrictive, lack intuitiveness and consistency, and lastly convention is fine, but policy is not. for example, the convention of how a project is organized is fine (as long as it can be modified), only policies a build system should have are the policies the person deploying the build system defines.

implicit versus explicit build systems. this is another design/implementation consideration. i'm neither a fan of ant or maven, but there is one big difference between the 2. ant is explicit and maven is implicit. with ant a person can understand the basic workings of a build with little or no documentation. with maven, even after reading 'maven definitive quide' a couple times, most people will still struggle with maven... because it does very few things naturally. developer tools, especially build tools need to be explicit, and they need to be reasonably intuitive such that when a person that seldom works on the build system, has to get something done, they can rely on their intuition.

lots of people expressed their frustration with ant, but what I've seen in a number of companies is much more frustration with maven.

i started off this message stating the configuration of a build system should be 100% independent of the build system, at the same time, so should all the tasks. Another words a build system should work as a hub to work from a build model and apply actions that are not bound to the build systems api. Tasks and Plugins... Plugins should be to only extend the build system, not to define tasks. Tasks should be 100% independent of the build system. What we want is a loosely coupled design and implementation.

i think the next really good build system will not show up as a tool that pops up in open source, but instead a discussion on what the build system eco-system should look like, and from that a discussion on design and implementation.

ant and maven feel like they were streams-of-thought translated into code.
</pre>