Hi Jason,

On Oct 7, 2008, at 10:55 AM, Jason Dillon wrote:

<snip>

Really? Jelly was a buggy unmaintained scripting language. This was at the base of Maven1 and this was a dramatic problem. I remember the Maven guys saying for Maven 2 something like: 'We don't even start to _think_ about supporting Groovy unless there is a 1.0 release'. For those who don't know this: This was owned to the fact that James has been the creator of both, Groovy and Jelly.

That is what I'm saying.

I mean the http://maven.apache.org/plugins/maven-enforcer-plugin/

This is an easy one:

See my work in progress document: http://docs.codehaus.org/download/ attachments/74383419/mavenDependencies.pdf

Also have a look at: http://ant.apache.org/ivy/m2comparison.html

Beside the many issues mentioned and shown in the documents above, the list is much longer. Ivy provides transaction policies for you caches. You can have as many caches as you want. You can define arbitrary patterns for repository layout. You can use regular expressions for inclusions, etc ...

I have worked with both, Maven and Ivy, intensely. I can only say it again: Ivy is light years ahead of Maven in regard to dependency management. Maven's dependency management is not very powerful, inflexible and conceptually flawed.

I had a multi-project build which had not one single inheritance chain. It was impossible for me to achieve this. I have tried to use project specific properties in a profiles.xml (which I have stored in the root project folder) which also did not work out. The only solution I have found with projects that had a similar scenario was to use XML Entity Inclusion. I had no time yet to set up a sample project for this. But I doubt that you would find a solution.

I mean actions in the general sense of the word. This is about comparing build systems. So I don't want to use Maven terminology for this.

In Maven terminology I don't mean phases. I mean hooking plugin goals into phases.

LOL

You can't for example even configure that during the deploy phase the war plugin (which is associated with this phase by default) should _not_ deploy anything. At least you can't do this on a per project level, which is usually what is needed. And for example the default lifecycle phases are also always executed first by definition.

And how can you configure as a build-user such things on a per build basis? You can hook in goals to phases as a flat ordered list. That's it. This is far inferior to having an arbitrary deep acyclic graph of actions (generally speaking).

It is true for the use case I have provided.

I have done this with Maven. This is nice if you have one mulit- project build and want to use it to produce different distributions which require different subprojects. But this is no solution to the problem I have described, as you probably will know.

I can't see how this solves the the use case from above. Could you give more details?

Have a look at my comments above regarding the Maven lifecycle. This point is not about the good or bad qualitiy of certain aspects of Maven. This is about the general approach of Maven. Maven is a big framework. A Maven user can only move within this framework. But the build space is complex and the users have many requirements which can't be anticipated by the developers, however smart they are. In such cases any framework turns into an obstacle or prison. Gradle is _not_ a framework. It has a language for dependency based programming at its base and highly configurable frameworks can be plugged in. But you can always fall back to utmost flexibility. I have seen that this issue is discussed between you and Jochen in some other postings in this thread. So I will write more about it there.

- Hans