Dean Schulze wrote:
"... I always end up just trying a bunch of stuff that looks like it
should be right. Fortunately, within four or five tries I get it right."
I share your pain. I haven't been able to figure out how to incorporate
gradle into my existing projects either, and I don't have the time to
futz with it.
I don't know why gradle has to have this barrier to entry. An
experienced Java/Ant developer should be able to pick up a groovy based
build system quickly, but for some reason that isn't the case with
gradle. Gradle has turned out to be more like Maven than Ant when it
comes to learning curve.
I wonder if the key to this problem is gradle's convention-based
mentality. Most existing projects don't follow gradle's convention.
They are all over the place. Refactoring existing projects to meet the
gradle/Maven2 conventions is the tail wagging the dog and that will
prevent gradle adoption and keep it a niche product. In this way
convention based build tools have become an obstacle instead of a useful
tool.
I'm counter to this... the Java plugin was perfect for me. My build was
already arranged in the right form for it (mostly). I was even able to
trick it into building multiple projects out of the same source tree.
That part actually went quite well. My meta-jb project uses this to
build it's various sub-components out of one source tree. I was loathe
to take on the challenge of trying to separate everything and I actually
find it convenient that everything is nearby.
You're right when you say we need non-trivial examples. Especially
examples that don't follow the gradle/Maven2 convention.
I've heard that it is easy to modify the Java plugin for other project
structures - unless your tests are in the src/ directory. It sounds
like what we need are real examples of modifying the Java plugin to work
with some non-conventional project structures, or maybe even examples of
how to write out own plugins for existing project structures.
I _long_ ago moved my test classes out of the src directory because it
causes tons of problems and solves none. When first starting with ANT
(coming from gmake), we'd have src/java and test/java parallel
hierarchies. It just made things so much cleaner on every level. This
was pretty easy to move into a more maven-like directory structure for
the projects that I needed it.
I also recently tried using the groovy AntBuilder tool as an alternative
to Ant itself, but AntBuilder is broken. Instantiating an AntBuilder throws
java.lang.NoClassDefFoundError: org/apache/tools/ant/DemuxInputStream
http://www.groovy-forum.org/viewtopic.php?p=1128&sid=03569a338075bc1a5881a4eaa4e9222f#1128
This happnes in Eclipse. (Yes I've changed my Ant Home setting to Ant
1.7.1 instead of whatever version of Ant comes bundled with Eclipse.)
Maybe it would work outside of Eclipse, but if I can't use it from
within Eclipse it's no good for me.
Other people have seen this Exception and I've posted it to the groovy
forum, but no one responds. There was a Thread about this a couple of
months ago where Guillaume Laforge finally asked if the poster if he had
found a work around. The poster replied that his work around was to go
back to the Java way:
http://www.gg3721.com/list/49/74177.html
Groovy-based build tools should be good, but they arent. Trying to
adopt groovy-based build tools has been a waste of time. Maybe Ant is
still the best build tool out there.
I'm actually ok with gradle. I'm still on 0.5.2 though because I
haven't had time to figure out the "new syntax". A risk from using a
tool in its infancy.
However, it has allowed me to tame my project->project dependencies and
to produce maven pom files for upload to public repositories. In fact,
I dropped maven support altogether because I think gradle produces nicer
public poms.
All of my major frustrations to date have been trying to reconcile the
ant documentation, the groovy documentation, and the gradle
documentation to do something I already could have figured out in ant.
Invariably, once I finally have the ant-like thing working in gradle it
is obvious but getting there is a challenge.
As compared to ANT, maven was wasting an average of about 8 hours a week
just on extra build time and build configuration issues. Gradle is now
probably closer to 3-4 hours and I expect that to improve over time.
In ANT, everything has an example. Gradle will eventually get there, I
think. Having one non-trivial build.xml ported directly to a
build.gradle (without plugins) would be tremendously useful for those of
us who don't dream in groovy yet.
-Paul
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
