Roadmap Document

[hdockter]

We want to make our roadmap document more helpful for the community.  
So far the roadmap was a static website which didn't get much  
attention and had a lot of stale information. We have now moved the  
roadmap to our Wiki. This enables user comments, makes it easier to  
update and thus hopefully less stale. For the release in progress we  
indicate also which features are already implemented in trunk.

The new roadmap document can be found here: http://docs.codehaus.org/display/GRADLE/Roadmap

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org


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

    http://xircles.codehaus.org/manage_email

[Andreas Jöcker]

Hi all,

I'm just started to get to know to gradle and would like to use it more
heavily in our projects.
I read the wonderful User's guide but what I miss is a simple build file
example (or was I too blind to see it ?)
The user guide shows nicely several parts of a building system, but a
simple example would be nice.

Can anyone point me to something or give me an example of a simple build
file in gradle, which e.g. has dependencies, compiles, builds a jar /
war or whatever.

I just want to see some real file to see the syntax working....

Thanks for that
Andreas

--

Andreas Jöcker
GiS - Gesellschaft für integrierte Systemplanung mbH
Junkersstr. 2
69469 Weinheim

E-Mail   a.joecker@...
Telefon [phone]
Fax     [phone]

Gesellschaft für integrierte Systemplanung mbH
Geschäftsführer: Eckhard Haffmann, Alfred Gai, Bernd Heselmann
Sitz der Gesellschaft: Zeppelinstr. 11 - 91052 Erlangen
Amtsgericht Fürth/Bayern - Handelsregister-Nr. HRB 3435


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

    http://xircles.codehaus.org/manage_email

[hdockter]

On Jun 4, 2009, at 9:20 AM, Andreas Jöcker wrote:

> Hi all,
>
> I'm just started to get to know to gradle and would like to use it  
> more
> heavily in our projects.
> I read the wonderful User's guide but what I miss is a simple build  
> file
> example (or was I too blind to see it ?)
> The user guide shows nicely several parts of a building system, but a
> simple example would be nice.
>
> Can anyone point me to something or give me an example of a simple  
> build
> file in gradle, which e.g. has dependencies, compiles, builds a jar /
> war or whatever.
>
> I just want to see some real file to see the syntax working....

There is one in the user's guide. For example UG 6.1.5: http://gradle.org/0.6.1/docs/userguide/tutorial_java_projects.html#N1040A

Additionally the gradle distribution comes shipped with a samples  
directory. Samples you might be interested in are webApplication/
quickstart and java/quickstart and java/multiproject.

We plan to add an Appendix with those samples to the user's guide.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org


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

    http://xircles.codehaus.org/manage_email

[Andreas Jöcker]

thanks Hans - I knew I'm just too blind....

will have also a look into the distribution.

Cheers
Andreas

Am 04.06.2009 09:31, Hans Dockter schrieb:

> On Jun 4, 2009, at 9:20 AM, Andreas Jöcker wrote:
>
>  
>> Hi all,
>>
>> I'm just started to get to know to gradle and would like to use it  
>> more
>> heavily in our projects.
>> I read the wonderful User's guide but what I miss is a simple build  
>> file
>> example (or was I too blind to see it ?)
>> The user guide shows nicely several parts of a building system, but a
>> simple example would be nice.
>>
>> Can anyone point me to something or give me an example of a simple  
>> build
>> file in gradle, which e.g. has dependencies, compiles, builds a jar /
>> war or whatever.
>>
>> I just want to see some real file to see the syntax working....
>>    
>
> There is one in the user's guide. For example UG 6.1.5: http://gradle.org/0.6.1/docs/userguide/tutorial_java_projects.html#N1040A
>
> Additionally the gradle distribution comes shipped with a samples  
> directory. Samples you might be interested in are webApplication/
> quickstart and java/quickstart and java/multiproject.
>
> We plan to add an Appendix with those samples to the user's guide.
>
> - Hans
>
> --
> Hans Dockter
> Gradle Project Manager
> http://www.gradle.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>  

--

Andreas Jöcker
GiS - Gesellschaft für integrierte Systemplanung mbH
Junkersstr. 2
69469 Weinheim

E-Mail   a.joecker@...
Telefon [phone]
Fax     [phone]

Gesellschaft für integrierte Systemplanung mbH
Geschäftsführer: Eckhard Haffmann, Alfred Gai, Bernd Heselmann
Sitz der Gesellschaft: Zeppelinstr. 11 - 91052 Erlangen
Amtsgericht Fürth/Bayern - Handelsregister-Nr. HRB 3435


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

    http://xircles.codehaus.org/manage_email

[dwschulze-2]

Andreas,

I had the same question you did after reading the first several chapters of the User's Guide.  I recently posted my question on this list.

What the User's Guide doesn't explain is that Gradle is a convention-based build system.  The gradle build examples that come with the distribution are surprisingly short.  They don't need to declare many of the things that you would declare with Ant because they follow the gradle (Maven2) convention.  It's built into gradle and the Java Plugin by default.

The problem comes when you have to adapt gradle to an existing project strucure.  You're faced with re-defining the conventions that gradle expects.  Others have told me that it's not that difficult to do, but I haven't had time to try it so far.

The User's Guide needs to be re-written.  It just leaves you scratching your head the way it is now.  It also needs to show how to re-define the Java Plugin for the various ways that existing Java/J2EE projects are structured.

Good luck.

--- On Thu, 6/4/09, Andreas Jöcker <a.joecker@...> wrote:

From: Andreas Jöcker <a.joecker@...>
Subject: [gradle-user] A naive question
To: user@...
Date: Thursday, June 4, 2009, 1:20 AM

Hi all,

I'm just started to get to know to gradle and would like to use it more
heavily in our projects.
I read the wonderful User's guide but what I miss is a simple build file
example (or was I too blind to see it ?)
The user guide shows nicely several parts of a building system, but a
simple example would be nice.

Can anyone point me to something or give me an example of a simple build
file in gradle, which e.g. has dependencies, compiles, builds a jar /
war or whatever.

I just want to see some real file to see the syntax working....

Thanks for that
Andreas

--

Andreas Jöcker
GiS - Gesellschaft für integrierte Systemplanung mbH
Junkersstr. 2
69469 Weinheim

E-Mail   a.joecker@...
Telefon [phone]
Fax     [phone]

Gesellschaft für integrierte Systemplanung mbH
Geschäftsführer: Eckhard Haffmann, Alfred Gai, Bernd Heselmann
Sitz der Gesellschaft: Zeppelinstr. 11 - 91052 Erlangen
Amtsgericht Fürth/Bayern - Handelsregister-Nr. HRB 3435


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

    http://xircles.codehaus.org/manage_email

[hdockter]

> What the User's Guide doesn't explain is that Gradle is a convention-
> based build system.

I see this differently. Gradle offers optional plugins that allow for  
convention based builds. You don't need to use and still have a  
powerful general purpose build tool.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org


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

    http://xircles.codehaus.org/manage_email

[Paul Speed-2]

Hans Dockter wrote:
>> What the User's Guide doesn't explain is that Gradle is a
>> convention-based build system.
>
> I see this differently. Gradle offers optional plugins that allow for
> convention based builds. You don't need to use and still have a powerful
> general purpose build tool.
>

I haven't looked at the latest docs so I'm only going from the 0.5.2
ones but maybe what is needed are a few non-plug-in, non-trivial
examples.  I know I can do everything in gradle that I could do in ANT
but not being a groovy expert and not knowing ant builder well (or
whatever the ant-groovy thing is), 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.

Sometimes I can find a near enough example in the documentation but I
almost have to completely re-read it to pick those gems out.

Not trying to be overly critical...
-Paul


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

    http://xircles.codehaus.org/manage_email

[Russel Winder-4]

On Thu, 2009-06-04 at 14:44 -0400, Paul Speed wrote:
>
> Hans Dockter wrote:
> >> What the User's Guide doesn't explain is that Gradle is a
> >> convention-based build system.
> >
> > I see this differently. Gradle offers optional plugins that allow for
> > convention based builds. You don't need to use and still have a powerful
> > general purpose build tool.

I think it is important that sight of this point is not lost:  Gradle is
a generalized relationship resolution and Groovy code execution
framework on which a convention-based build framework is layered.

> I haven't looked at the latest docs so I'm only going from the 0.5.2
> ones but maybe what is needed are a few non-plug-in, non-trivial
> examples.  I know I can do everything in gradle that I could do in ANT
> but not being a groovy expert and not knowing ant builder well (or
> whatever the ant-groovy thing is), 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.
>
> Sometimes I can find a near enough example in the documentation but I
> almost have to completely re-read it to pick those gems out.
>
> Not trying to be overly critical...

It is true that criticism is often taken as a negative view of
something, but that is not actually true in English, criticism means to
make a judgement about something.  This can actually be praise for
something as well as the more usual negative thing.

Being critical is good. :-)

At the risk of being accused of being a rampant self-publicist:  I am at
the minute trying to justify to myself writing a book on Gradle.  This
would be a technical publication -- so aimed at practicing (and
practising as well :-) programmers with both the Groovy aware and Groovy
ignorant in mind.  The book would be example and use case driven and
would complement, augment and be different from all the online materials
that Hans, Adam, et al. maintain.  I have made a start on it, but as I
say there are issues.  The most important of these is how to make money
from the book, either directly or indirectly, so that I can fully
justify writing it -- as opposed to working on other books of which
there are three others vying for my time.

Currently Gradle is such a small project with so little take up
(relative to Ant, Maven, Make, etc.), that the likes of O'Reilly,
Pragmatic Programmers, APress, Manning are really not that interested,
though I could contact them again about this.  The alternative is to
self-publish in some way or another.  This is an increasingly serious
route given Amazon and others print on demand systems.

--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel@...
Concertant LLP        t: [phone], [phone]
41 Buckmaster Road,   f: [phone]   voip: sip:russel.winder@...
London SW11 1EN, UK   m: [phone]   skype: russel_winder

[Andreas Jöcker]

> I think it is important that sight of this point is not lost:  Gradle is
> a generalized relationship resolution and Groovy code execution
> framework on which a convention-based build framework is layered.
>  
As nice as this sounds - in my eyes this is not understandable for a
layman as me... great words but what do they mean ?
You also have to keep the balance between the correct description and
the simplicity of the words - they go sometimes hand in hand... but
sometimes the correct description makes it unreadable

my 2cents (sorry I'm to biased because of german law descriptions *g)
Andreas

--

Andreas Jöcker
GiS - Gesellschaft für integrierte Systemplanung mbH
Junkersstr. 2
69469 Weinheim

E-Mail   a.joecker@...
Telefon [phone]
Fax     [phone]

Gesellschaft für integrierte Systemplanung mbH
Geschäftsführer: Eckhard Haffmann, Alfred Gai, Bernd Heselmann
Sitz der Gesellschaft: Zeppelinstr. 11 - 91052 Erlangen
Amtsgericht Fürth/Bayern - Handelsregister-Nr. HRB 3435


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

    http://xircles.codehaus.org/manage_email

[Tom Eyckmans]

2009/6/4 Hans Dockter <mail@...>

We want to make our roadmap document more helpful for the community. So far the roadmap was a static website which didn't get much attention and had a lot of stale information. We have now moved the roadmap to our Wiki. This enables user comments, makes it easier to update and thus hopefully less stale. For the release in progress we indicate also which features are already implemented in trunk.

The new roadmap document can be found here: http://docs.codehaus.org/display/GRADLE/Roadmap

The new page looks nice :) 

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org


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

  http://xircles.codehaus.org/manage_email

[dwschulze-2]

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

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



--- On Thu, 6/4/09, Paul Speed <pspeed@...> wrote:

From: Paul Speed <pspeed@...>
Subject: Re: [gradle-user] A naive question
To: user@...
Date: Thursday, June 4, 2009, 12:44 PM

Hans Dockter wrote:
>> What the User's Guide doesn't explain is that Gradle is a convention-based build system.
>
> I see this differently. Gradle offers optional plugins that allow for convention based builds. You don't need to use and still have a powerful general purpose build tool.
>

I haven't looked at the latest docs so I'm only going from the 0.5.2
ones but maybe what is needed are a few non-plug-in, non-trivial
examples.  I know I can do everything in gradle that I could do in ANT
but not being a groovy expert and not knowing ant builder well (or
whatever the ant-groovy thing is), 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.

Sometimes I can find a near enough example in the documentation but I
almost have to completely re-read it to pick those gems out.

Not trying to be overly critical...
-Paul


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

   http://xircles.codehaus.org/manage_email

[Paul Speed-2]

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

[Adam Murdoch-2]

Dean Schulze wrote:

Andreas,

I had the same question you did after reading the first several chapters of the User's Guide.  I recently posted my question on this list.

What the User's Guide doesn't explain is that Gradle is a convention-based build system.  The gradle build examples that come with the distribution are surprisingly short.  They don't need to declare many of the things that you would declare with Ant because they follow the gradle (Maven2) convention.  It's built into gradle and the Java Plugin by default.

The problem comes when you have to adapt gradle to an existing project strucure.  You're faced with re-defining the conventions that gradle expects.  Others have told me that it's not that difficult to do, but I haven't had time to try it so far.

The User's Guide needs to be re-written.

Re-written? Wow. Why do you think that? How would you suggest we structure it differently? What questions did you have that it did not answer? If you have any ideas, you could help out by adding them to the wiki at http://docs.codehaus.org/display/GRADLE/User+guide

From your comments so far, it seems like all the user guide has to do is explain that Gradle provides an optional Java plugin, which you can use to build a JAR from a Java project if you want. This plugin takes care of the work of compiling, testing and JARing your project for you, and it uses some default locations to find source and tests and various other things (AKA the convention), all of which you can change if you like. If you want to use the convention, you don't need to do anything at all in your build file. If you don't want to use the convention, you need to tell Gradle where various things are by settings some properties. Oh, and here's an example asking the plugin to look for source under src/ and the tests under src/test.

Would that do?

  It just leaves you scratching your head the way it is now.  It also needs to show how to re-define the Java Plugin for the various ways that existing Java/J2EE projects are structured.

That problem is, the examples are structured how pretty much every Java project I've ever worked on have been structured. So, you're going to have to help us out here. We can't write about what we don't know. How are your Java/J2EE project different to our examples? Is it simply that the source is under src/ and the tests are under src/tests? Or is there something else?

Good luck.

--- On Thu, 6/4/09, Andreas Jöcker a.joecker@... wrote:

From: Andreas Jöcker a.joecker@...
Subject: [gradle-user] A naive question
To: user@...
Date: Thursday, June 4, 2009, 1:20 AM

Hi all,

I'm just started to get to know to gradle and would like to use it more
heavily in our projects.
I read the wonderful User's guide but what I miss is a simple build file
example (or was I too blind to see it ?)
The user guide shows nicely several parts of a building system, but a
simple example would be nice.

Can anyone point me to something or give me an example of a simple build
file in gradle, which e.g. has dependencies, compiles, builds a jar /
war or whatever.

I just want to see some real file to see the syntax working....

Thanks for that
Andreas

--

Andreas Jöcker
GiS - Gesellschaft für integrierte Systemplanung mbH
Junkersstr. 2
69469 Weinheim

E-Mail   a.joecker@...
Telefon [phone]
Fax     [phone]

Gesellschaft für integrierte Systemplanung mbH
Geschäftsführer: Eckhard Haffmann, Alfred Gai, Bernd Heselmann
Sitz der Gesellschaft: Zeppelinstr. 11 - 91052 Erlangen
Amtsgericht Fürth/Bayern - Handelsregister-Nr. HRB 3435


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

    http://xircles.codehaus.org/manage_email

[Adam Murdoch-2]

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.

It would be really helpful if you could. One of the design goals of the Java plugin is that it must easily adapt to a wide range of project layouts. You should not have to change your layout at all in order to use the Java plugin - though the further you are away from the convention, the more work you will have to do in your build file. From what you've described so far, the Java plugin will handle your layout easily. It would be nice to prove that is the case, and to fix the plugin if it is not.

Here's a starting point for you:

usePlugin 'java'
srcRootName = ''
srcDirNames = ['src']
testSrcDirNames = ['src/tests']

compile.exclude 'tests/**'

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 believe the problem is documentation. Gradle *is* extremely flexible, by design, and for exactly the reason you mention above. We just need to help you figure out how to tell Gradle where stuff is.

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.

You, or anyone else, can help us out here. You can try to get Gradle working with one of your projects and you could then post an example to the wiki. From there, they can end up in the user guide.

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.



--- On Thu, 6/4/09, Paul Speed pspeed@... wrote:

From: Paul Speed pspeed@...
Subject: Re: [gradle-user] A naive question
To: user@...
Date: Thursday, June 4, 2009, 12:44 PM

Hans Dockter wrote:
>> What the User's Guide doesn't explain is that Gradle is a convention-based build system.
>
> I see this differently. Gradle offers optional plugins that allow for convention based builds. You don't need to use and still have a powerful general purpose build tool.
>

I haven't looked at the latest docs so I'm only going from the 0.5.2
ones but maybe what is needed are a few non-plug-in, non-trivial
examples.  I know I can do everything in gradle that I could do in ANT
but not being a groovy expert and not knowing ant builder well (or
whatever the ant-groovy thing is), 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.

Sometimes I can find a near enough example in the documentation but I
almost have to completely re-read it to pick those gems out.

Not trying to be overly critical...
-Paul


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

   http://xircles.codehaus.org/manage_email

[Walter Di Carlo-2]

2009/6/5 Adam Murdoch <a@...>:
>
> That problem is, the examples are structured how pretty much every Java
> project I've ever worked on have been structured. So, you're going to have
> to help us out here. We can't write about what we don't know. How are your
> Java/J2EE project different to our examples? Is it simply that the source is
> under src/ and the tests are under src/tests? Or is there something else?
>

Let me add my 2 cents. I think the user guide is oriented most to
people coming from Maven way to manage a Java project. What about
people, like me, not coming from such world? In my case, for example,
I am doing the following steps to transform a big java project into a
set of decoupled multi java projects managed with Gradle:

1) Split the java project into less-coupled java components
    - different jars are generated from the same project
    - build and jar creation are delegated to the IDE
    - use simple jar names
2) Create a project for each component
    - one or more jars created by each project
    - dependencies managed by IDE
    - build and jar creation are delegated to the IDE
    - use simple jar names
3) Add Ant scritps in each project to make them indipendent of the IDE
    - build and jar creation are delegated to the Ant scripts
    - dependencies managed by IDE or by hand
    - use simple jar names
4) Add Gradle to manage project dependencies
    - build and jar creation are delegated to the Ant scripts
    - use flat local repository for the build resolver
    - use simple jar names
    - dependencies managed by Gradle
    - use Ant wrapper to call Gradle
5) Use Gradle also to build and create jars
    - use flat local repository for the build resolver
    - use simple jar names
    - dependencies managed by Gradle
6) Adopt multi-version repository
    - use jar names with versions
    - may access remote common lib repository

Currently, I am in the step 4. These steps are needed because most of
the developers are confortable with Ant. So, they want to delay/reduce
as much as possible the introduction/impact of a tool like Gradle.
Does all this make sense and help to better figure out what can be
added to the user guide?

In any case, Gradle has proofed to be very flexible for me, but this
leaves me with the feeling to use it not in the right way. For
example, now, I am managing the flat repository with some custom code
I have added to the compile/jar tasks. I am sure this is not the
correct way but I have not found/understood how I could do it in the
right way.

Regards,

Walter

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

    http://xircles.codehaus.org/manage_email

[dwschulze-2]

Adam,

Your "starting point" below is exactly what I need, and I think it is what others need too.

We must be living in different worlds (planet Maven and planet Earth).  I've never worked on -- and can't even remember seeing -- a project with the structure src/main for Java code.  Look at how eclipse creates projects for Java and J2EE.  The source code goes in src/.  Some projects that put it into src/java.  (Yes, it is configurable in Eclipse, but src/ is the default.)

Why not use the Eclipse defaults?  It's the most widely used IDE.  (I can't remember where IntelliJ and NetBeans put Java source by default.)

Please expand more on your starting points.  Some other immediate issues:

Building .war files:

  How do I build a .war if my deployment descriptors are in etc/, conf/, or somewhere else?

  I use a convention for third party jar files that works like this:

    lib/vendor_name/product_name/version_number/something.jar

  How do I tell Gradle to put certain .jar files into WEB-INF/lib, but not others?

That should get me started so I can ask better questions.






--- On Fri, 6/5/09, Adam Murdoch <a@...> wrote:

From: Adam Murdoch <a@...>
Subject: Re: [gradle-user] A naive question
To: user@...
Date: Friday, June 5, 2009, 3:30 PM

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.

It would be really helpful if you could. One of the design goals of the Java plugin is that it must easily adapt to a wide range of project layouts. You should not have to change your layout at all in order to use the Java plugin - though the further you are away from the convention, the more work you will have to do in your build file. From what you've described so far, the Java plugin will handle your layout easily. It would be nice to prove that is the case, and to fix the plugin if it is not.

Here's a starting point for you:

usePlugin 'java'
srcRootName = ''
srcDirNames = ['src']
testSrcDirNames = ['src/tests']

compile.exclude 'tests/**'

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 believe the problem is documentation. Gradle *is* extremely flexible, by design, and for exactly the reason you mention above. We just need to help you figure out how to tell Gradle where stuff is.

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.

You, or anyone else, can help us out here. You can try to get Gradle working with one of your projects and you could then post an example to the wiki. From there, they can end up in the user guide.

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.



--- On Thu, 6/4/09, Paul Speed <pspeed@...> wrote:

From: Paul Speed <pspeed@...>
Subject: Re: [gradle-user] A naive question
To: user@...
Date: Thursday, June 4, 2009, 12:44 PM

Hans Dockter wrote:
>> What the User's Guide doesn't explain is that Gradle is a convention-based build system.
>
> I see this differently. Gradle offers optional plugins that allow for convention based builds. You don't need to use and still have a powerful general purpose build tool.
>

I haven't looked at the latest docs so I'm only going from the 0.5.2
ones but maybe what is needed are a few non-plug-in, non-trivial
examples.  I know I can do everything in gradle that I could do in ANT
but not being a groovy expert and not knowing ant builder well (or
whatever the ant-groovy thing is), 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.

Sometimes I can find a near enough example in the documentation but I
almost have to completely re-read it to pick those gems out.

Not trying to be overly critical...
-Paul


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

   http://xircles.codehaus.org/manage_email

[hdockter]

On Jun 6, 2009, at 1:06 AM, Walter Di Carlo wrote:

> 2009/6/5 Adam Murdoch <a@...>:
>>
>> That problem is, the examples are structured how pretty much every  
>> Java
>> project I've ever worked on have been structured. So, you're going  
>> to have
>> to help us out here. We can't write about what we don't know. How  
>> are your
>> Java/J2EE project different to our examples? Is it simply that the  
>> source is
>> under src/ and the tests are under src/tests? Or is there something  
>> else?
>>
>
> Let me add my 2 cents. I think the user guide is oriented most to
> people coming from Maven way to manage a Java project. What about
> people, like me, not coming from such world? In my case, for example,
> I am doing the following steps to transform a big java project into a
> set of decoupled multi java projects managed with Gradle:
>
> 1) Split the java project into less-coupled java components
>    - different jars are generated from the same project
>    - build and jar creation are delegated to the IDE
>    - use simple jar names
> 2) Create a project for each component
>    - one or more jars created by each project
>    - dependencies managed by IDE
>    - build and jar creation are delegated to the IDE
>    - use simple jar names
> 3) Add Ant scritps in each project to make them indipendent of the IDE
>    - build and jar creation are delegated to the Ant scripts
>    - dependencies managed by IDE or by hand
>    - use simple jar names
> 4) Add Gradle to manage project dependencies
>    - build and jar creation are delegated to the Ant scripts

>    - use flat local repository for the build resolver
>    - use simple jar names
>    - dependencies managed by Gradle
>    - use Ant wrapper to call Gradle

It might be interesting for you to know that with Gradle trunk you can  
import any build.xml and the Ant targets are integrated as Gradle  
tasks. That way you might be able to reverse the way things are  
executed.

> 5) Use Gradle also to build and create jars
>    - use flat local repository for the build resolver
>    - use simple jar names
>    - dependencies managed by Gradle
> 6) Adopt multi-version repository
>    - use jar names with versions
>    - may access remote common lib repository
>
> Currently, I am in the step 4. These steps are needed because most of
> the developers are confortable with Ant. So, they want to delay/reduce
> as much as possible the introduction/impact of a tool like Gradle.
> Does all this make sense and help to better figure out what can be
> added to the user guide?

As I understand this Ant integration need to get better coverage. This  
is already work in progress. I'm not sure what in the user's guide is  
missing to implement 5.) for 6.). I guess we would need more details  
for this.

>
> In any case, Gradle has proofed to be very flexible for me, but this
> leaves me with the feeling to use it not in the right way.

I know you had a couple of postings a while ago and we were not very  
responsive at that time. We were very busy with our 0.6 release.  
Apologies for that. Please ask about any of the open issues you have  
and we are happy to help.

> For
> example, now, I am managing the flat repository with some custom code
> I have added to the compile/jar tasks. I am sure this is not the
> correct way but I have not found/understood how I could do it in the
> right way.

Is this about getting your jars created by Gradle into a flat  
repository?

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org


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

    http://xircles.codehaus.org/manage_email