Hi Martin,
sorry for not answering earlier. I was very busy with the release.
On May 5, 2008, at 10:58 PM, Martin Stephan wrote:
Hi,
this is a message I actually posted on groovy-user in the topic
"Gradle usage", however it might be more suitable for this list.
Maybe someone could enlighten me. Even an RTFM with the pointer to
suitable documentation would be appreciated as I wasn't able to
find any books/articles that actually discuss the topic ant vs
maven vs gmaven vs gant vs mojo vs gradle vs ivy whatnot. I suppose
I could leave all the 'Gs' out of the equation and simply decide if
like ant (+ivy) better than maven or the other way around. However,
from what I read, gradle seems to be a new animal in that regard,
as it seems to try a best of *all* worlds approach..
---
I actually am confronted with the same decision. Gant or Gradle,
that is. So far I always used the build support of my IDE for the
little tools I write for my job. But since I'm trying new stuff
with groovy, I thought, I might go all the way and started looking
into ant, maven, gant, gradle.
Long story short, I started with gradle. Worked okaish for me,
since it was nice to have prepared targets but my problem was that
the didn't quite do what I wanted, i.e. the jar target
(myclass_jar) jars everything including the libs alright, but
doesn't create a 'fat jar' with groovy-embeddable-*.jar.
So, I figured, I needed to modify that target, but didn't know how.
Or maybe use dependencies, but wasn't too sure about that either,
especially since I don't have any maven or ivy repos yet. So I
thought about creating a new target which did what I wanted. This I
can do in gant and gradle, but doing that in gradle would make all
the standardization quite useless, I think.
Now I have a working build.gant file which does exactly what I
want, but I'm still wondering if I could have done all that in
gradle while keeping it 'standardized' somehow.
Gradle is a general purpose build tool. It has all the flexibility
offered by Ant or Gant or other general purpose build tools. Its
perfectly suitable for non standardized Ant scripting if this is the
best way to do the job.
On top of this general purpose layer Gradle has a build-by-convention
framework. It is very important to see that Gradle _is_ not a build-
by-convention build tool. It just offers also build-by-convention
behavior. The build problem space is complex. We think build-by-
convention makes only sense, if it let you do the things not captured
by the framework in an easy way.
Unfortunately I'm very tired right now. Therefore I gonna send a
second mail tomorrow showing how to create your fat jar with Gradle.
Thanks for your patience
- Hans
I would be very grateful for any hints. I suppose I missed some
important parts of the gradle documentation..
Martin
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
