Easing the Ant (nad Maven) -> Gradle path

[Russel Winder-4]

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.  Some immediate thoughts
though:

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.

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.

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.)

More later, thanks.
--
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: [phone], [phone]
41 Buckmaster Road,              f: [phone]
London SW11 1EN, UK.             m: [phone]

[Adam Murdoch-2]

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.

>  Some immediate thoughts
> though:
>
> 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 :)

> 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.

> 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.


Adam

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Russel Winder-4]

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: [phone], [phone]
41 Buckmaster Road,              f: [phone]
London SW11 1EN, UK.             m: [phone]