Adam, On Fri, 2008-10-10 at 18:38 +1100, Adam Murdoch wrote: > > Russel Winder wrote: > > I will spend some time over the next few days and weeks trying to use > > Gradle as a Gant replacement. I will also look to create a Gradle Ant > > task and using Ant XML scripts from Gradle. > > Both these things would be very cool. As would a Gradle Gradle task.
Not sure about the third of these but the first two are more or less ready in Gant and I am fairly sure easily transported to Gradle. A classic Gant question is how can I call Gant from Gant to handle sub-projects -- this is in direct analogy with the <ant> tag and involves doing a ( new Gant ( ... ) ). I am wondering if the Gradle philosophy is such that the whole idea of sub-Gradle calls is anathema? > > 1. I need to find out how Gradle supports what in Gant are called tools > > and target sets. Basically this is the partitioning of bits of build > > script into reusable components. This is not plugins a la Java plugin > > or Groovy plugin, though these do much of what Gant target sets do (but > > they are a bit different). If anyone has any hints and help to assist > > me building up the right idioms quickly that would be most helpful. > > There's really only plugins and tasks. I reckon it wouldn't be too > difficult to put together a plugin which could import tools and target > sets into Gradle (based on my pretty sketchy understanding of what tools > and target sets are :) I need to spend time studying the Gradle features in more detail. Unfortunately, I have do some JavaME stuff next week so may not find time to more interesting things like Gradle :-) > > 2. I can guarantee that using the label createTask instead of target is > > going to create barriers to entry for Ant people (trivial I know but the > > biggest barriers are often the most trivial ones). I am almost > > certainly going to propose an alias for createTask so that Gradle > > scripts can look more or less like Gant scripts since this has created a > > very low barrier to entry for Ant people. > > If we do this, I think it belongs in an ant compatibility plugin, rather > than the core. That certainly works for me. The question then is what draws people away from using the notation of the compatibility mode? > > 3. The use of the -q option everywhere in the documentation is going to > > be another of those very trivial things that create a big barrier to > > entry. Gradle appears to have an option set that follows neither Ant > > or Maven and this creates potential for barriers to entry. Is there a > > table that maps idiomatic Ant and Maven use cases to Gradle use cases? > > > > 4. The manual needs to deal a lot more with the "replacement of Ant" > > and "replacement of Maven" aspects. Gradle is positioning itself to > > replace both Ant and Maven, but so far emphasizes the "configuration > > over configuration" and so gets thought of only as a Maven replacement > > using Ivy, the Ant replacement aspects do seem to be getting lost. > > (This is not a fact, just a perception.) > > I agree. Some stuff is starting to form for replacing maven, but nothing > really for ant yet. The problem with Gradle as Ant replacement really does revolve around the fact that the concepts of task and target are so very different -- even though actually they are not that different really. Part of the problem is that the smallest differences can end up as the biggest barriers. -- Russel. ==================================================== Dr Russel Winder Partner Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203 41 Buckmaster Road, f: +44 8700 516 084 London SW11 1EN, UK. m: +44 7770 465 077
signature.asc
Description: This is a digitally signed message part
