On Oct 8, 2008, at 6:30 PM, Hans Dockter wrote:

Or if you build is so simple then just use an plugin which you can embed into a single pom.xml, like antrun, gmaven, jruby, etc. There is no bizarre indirection here, just misconceptions or lack of understanding.

There is no reason why you couldn't code this up as I suggested, but your build would end up highly unpredictable and hard for folks familiar with Maven to comprehend. IMO thats not a very good thing.

Sure, things evolve... sometimes into monsters. My point was that the original vision was that Ant was not a scripting language. Have a look at "Ant: The Definitive Guide" from O'Reilly if you don't believe me.

No I was just being a smart-ass, cause I didn't (and still don't) buy the media breach concept.

How? How does using a Groovy DSL-based tool make anything more transparent than an XML-based tool? There is still plumbing in both which makes the damn thing work. If a developer doesn't know how the pipes fit, they are still clueless about what is going on.

Groovy and XML are on pair if you consider them both languages... then the DSL and XML Schema are then parallel on the level of knowledge that a developer must comprehend to use the tool.

So I see them basically as the same. Both require some additional learning on the part of the user to make affective use of the tool. Only difference is the underlying language, so I don't really see how a Groovy-based tool becomes any more transparent to a Groovy developer.

BUT... that said, I do like Groovy and have wished for a Groovy-pom many times, almost went and crafted up a system like Gradle to do what I want the way I want. . And I look forward to seeing where Gradle can go in the future. I'm not convinced yet that its a better tool than Maven is... yet. My personal opinion is that is not quite mature enough, but we'll see where things go.

On an unrelated note, it would be kinda cool if Gradle could invoke a Maven plugin, not just Ant tasks.

I use Maven2 because ATM I believe it to be the best tool out there for the wide variety of simple to complex build systems I work on. As I mentioned before that didn't use to be the case. Before M2 it was M1, before M1 it was Ant and before Ant it wash Make. So I've no problem eventually evolving into another tool, as long as it can do the job I need to perform.

If it was me, and I was using an unmanageable Ant build, I think my recommendation would still be to move towards M2, split up monolithic modules and then wait to see what other tools can provide when they reach a level of enterprise maturity. From what I gather, the changes to split up monolithic modules will have a lot of synergy with an eventual/potential switch to Gradle. So IMO its baby steps. My desire (besides having someone other than myself do the work and deal with the stress) is to end up with a more modular groovy-core build, which trims down the core classes while providing artifacts for the ancillary ones... such that any build supporting Ivy or M2 can resolve them easily to quickly make use of them.

I still don't think Gradle is ready to do that, but I'd be happy to be wrong and I'll be the first to buy you a beer to celebrate the success... though you'd have to come visit me in Thailand :-P

Bottom line... I look forward to seeing where Gradle goes... but for my builds I'm gonna stick with m2 for now.

--jason