Gradle Usage

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Gradle Usage

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

I would be very grateful for any hints. I suppose I missed some important parts of the gradle documentation..

Martin
Reply | Threaded
Open this post in threaded view
|

Re: Gradle Usage

hans_d
Administrator
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




Reply | Threaded
Open this post in threaded view
|

Re: Gradle Usage

Martin Stephan
Hello Hans,

no problem at all, especially since I knew you were working on a new release ;-) . But since I'm going on a business trip til Friday and my internet access and my time to access it might be limited somewhat I wanted to put my earlier message in context, since it was actually part of a thread.

I'm looking forward to your answer and in the meantime I'll look into the 0.1.4.

Regards

Martin

On Tue, May 6, 2008 at 1:01 AM, Hans Dockter <[hidden email]> wrote:
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





Reply | Threaded
Open this post in threaded view
|

Re: Gradle Usage

hans_d
Administrator
In reply to this post by hans_d
Hi Martin,

now the second part of my answer.

You could build your project like this:

usePlugin('java')
version = '1.0'
sourceCompatibility = 1.5targetCompatibility = 1.5
dependencies {    addFlatDirResolver('lib', file('libs'))    clientModule(['groovy'], ":groovy-all:1.6-beta-1") {        dependency(":commons-cli:1.0")    }    testCompile ":junit:4.4"}
libs.jar('myfat') {    fileSet(dir: classesDir)    AntDirective antDirective = new AntDirective()    antDirective.directive = {        zipgroupfileset(dir: new File(rootDir, 'lib'))    }    resourceCollections << antDirective    manifest.mainAttributes('Main-Class': 'org.myproject.Main')}
This is all you need. And you have dependency management which we think is something very valuable (see the chapter on dependencies). Its is not a thrilling yet I think a reasonable solution for your problem. In the next release of Gradle we want to offer a merge function where you can say:
my_jar {   merge(someJarFiles)}

That would be pretty nice. 

But there will be always features that are missing, It is essential that Gradle offers the flexibility to add custom behavior when there is no explicit support for a certain functionality.

We spend a lot of effort into our documentation. But the handling of archives deserves more coverage.

- Hans

P.S Here is the more or less corresponding Gant script (from Martin's mail to the Groovy user list):

// PrecheckinggroovyHome = System.getenv( ).'GROOVY_HOME'if((groovyHome == null) || (groovyHome == '')) {    println('GROOVY_HOME is not set, so a build cannot happen.')    return}

// Setup directories, mostly according to Maven/Cradle
final sourceDir = 'src/main/groovy'final libDir = 'src/lib'final buildDir = 'build'final buildClassesDir = buildDir + '/classes' final buildMetadataDir = buildClassesDir + '/META-INF'
// Setup infofinal projectName = 'Scriptcopy'final projectPackage = 'de.martinstephan'final projectMainClass = 'Scriptcopy'final projectPath = projectPackage.replace('.', '/')final jarPath = "${buildDir}/${projectName}.jar"final version = '0.1.0'
//  Set up all the targets.

includeTool << gant.tools.Execute
target(init: 'Init source directories.') {    Ant.mkdir(dir: 'src/main/groovy')} 
target(clean: 'Delete the compiled classes.') {    delete(dir: buildDir)}
Ant.taskdef(name: 'groovyc', classname: 'org.codehaus.groovy.ant.Groovyc')target(compile: 'Compile everything.' ) {    depends(clean)    Ant.mkdir(dir: buildClassesDir)    Ant.groovyc(srcdir: sourceDir , destdir: buildClassesDir)}
target(jar: 'Put everything in a jar') {    depends(compile)    Ant.jar(destfile: jarPath, compress: true, index: true ) {        fileset(dir: buildClassesDir, includes: "**/*.class")        zipgroupfileset(dir: groovyHome, includes: 'embeddable/groovy-all-*.jar')        zipgroupfileset(dir: groovyHome, includes: 'lib/commons-cli-*.jar')        //zipgroupfileset(dir: libdir, includes: '*.jar' )        // add more jars here
        manifest {            attribute(name: 'Main-Class', value: "${projectPackage}.${projectMainClass}")         }    }}
target(test: 'Test after compiling and jaring..') {    depends(jar)    Ant.java(jar: jarPath, fork: true) {        arg(value: '-s')        arg(value: 'testscript.xml')        //arg(value: '-h')    }}
target(_test: 'Test only..') {    Ant.java(jar: jarPath, fork: true) {        arg(value: '-s')        arg(value: 'testscript.xml')        //arg(value: '-h')    }}


On May 6, 2008, at 1:01 AM, Hans Dockter wrote:
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





--
Hans Dockter
Gradle Project lead




Reply | Threaded
Open this post in threaded view
|

Re: Gradle Usage

hans_d
Administrator
Hi Martin,

On May 6, 2008, at 10:49 AM, Hans Dockter wrote:
Hi Martin,

now the second part of my answer.

You could build your project like this:

usePlugin('java')
version = '1.0'
sourceCompatibility = 1.5targetCompatibility = 1.5
dependencies {    addFlatDirResolver('lib', file('libs'))    clientModule(['groovy'], ":groovy-all:1.6-beta-1") {        dependency(":commons-cli:1.0")    }    testCompile ":junit:4.4"}
libs.jar('myfat') {    fileSet(dir: classesDir)    AntDirective antDirective = new AntDirective()    antDirective.directive = {        zipgroupfileset(dir: new File(rootDir, 'lib'))    }    resourceCollections << antDirective    manifest.mainAttributes('Main-Class': 'org.myproject.Main')}
This is all you need. And you have dependency management which we think is something very valuable (see the chapter on dependencies). Its is not a thrilling yet I think a reasonable solution for your problem. In the next release of Gradle we want to offer a merge function where you can say:
my_jar {   merge(someJarFiles)}

the new lines got swallowed. Here a readable version:

usePlugin('java')
version = '1.0'
sourceCompatibility = 1.5
targetCompatibility = 1.5
dependencies {    
   addFlatDirResolver('lib', file('libs'))   
   clientModule(['groovy'], ":groovy-all:1.6-beta-1") {       
       dependency(":commons-cli:1.0")    
    }    
    testCompile ":junit:4.4"
}
libs.jar('myfat') {    
   fileSet(dir: classesDir)    
   AntDirective antDirective = new AntDirective()   
   antDirective.directive = {        
      zipgroupfileset(dir: new File(rootDir, 'lib'))    
   }    
   resourceCollections << antDirective    
   manifest.mainAttributes('Main-Class': 'org.myproject.Main')
}

This is all you need. And you have dependency management which we think is something very valuable (see the chapter on dependencies). Its is not a thrilling yet I think a reasonable solution for your problem. In the next release of Gradle we want to offer a merge function where you can say:

my_jar {   
   merge(someJarFiles)
}

That would be pretty nice. 

But there will be always features that are missing, It is essential that Gradle offers the flexibility to add custom behavior when there is no explicit support for a certain functionality.

We spend a lot of effort into our documentation. But the handling of archives deserves more coverage.

- Hans

P.S Here is the more or less corresponding Gant script (from Martin's mail to the Groovy user list):

// PrecheckinggroovyHome = System.getenv( ).'GROOVY_HOME'if((groovyHome == null) || (groovyHome == '')) {    println('GROOVY_HOME is not set, so a build cannot happen.')    return}

// Setup directories, mostly according to Maven/Cradle
final sourceDir = 'src/main/groovy'final libDir = 'src/lib'final buildDir = 'build'final buildClassesDir = buildDir + '/classes' final buildMetadataDir = buildClassesDir + '/META-INF'
// Setup infofinal projectName = 'Scriptcopy'final projectPackage = 'de.martinstephan'final projectMainClass = 'Scriptcopy'final projectPath = projectPackage.replace('.', '/')final jarPath = "${buildDir}/${projectName}.jar"final version = '0.1.0'
//  Set up all the targets.

includeTool << gant.tools.Execute
target(init: 'Init source directories.') {    Ant.mkdir(dir: 'src/main/groovy')} 
target(clean: 'Delete the compiled classes.') {    delete(dir: buildDir)}
Ant.taskdef(name: 'groovyc', classname: 'org.codehaus.groovy.ant.Groovyc')target(compile: 'Compile everything.' ) {    depends(clean)    Ant.mkdir(dir: buildClassesDir)    Ant.groovyc(srcdir: sourceDir , destdir: buildClassesDir)}
target(jar: 'Put everything in a jar') {    depends(compile)    Ant.jar(destfile: jarPath, compress: true, index: true ) {        fileset(dir: buildClassesDir, includes: "**/*.class")        zipgroupfileset(dir: groovyHome, includes: 'embeddable/groovy-all-*.jar')        zipgroupfileset(dir: groovyHome, includes: 'lib/commons-cli-*.jar')        //zipgroupfileset(dir: libdir, includes: '*.jar' )        // add more jars here
        manifest {            attribute(name: 'Main-Class', value: "${projectPackage}.${projectMainClass}")         }    }}
target(test: 'Test after compiling and jaring..') {    depends(jar)    Ant.java(jar: jarPath, fork: true) {        arg(value: '-s')        arg(value: 'testscript.xml')        //arg(value: '-h')    }}
target(_test: 'Test only..') {    Ant.java(jar: jarPath, fork: true) {        arg(value: '-s')        arg(value: 'testscript.xml')        //arg(value: '-h')    }}


On May 6, 2008, at 1:01 AM, Hans Dockter wrote:
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





--
Hans Dockter
Gradle Project lead





--
Hans Dockter
Gradle Project lead




Reply | Threaded
Open this post in threaded view
|

Re: Gradle Usage

Martin Stephan
Hi Hans,

thank you very much! I will play around with that and see what I can make of it.

So far I have two questions (after typing that from my smartphone screen while sitting in a train)

What's the deal with the AntDirective? Will a simple "ant.mkdir(dir:someDir) [for example] not also work? I haven't seen this in the documentation (not even the 0.1.4)

Also, your script creates another "myfat_jar" in addition to the existing "myclass_jar" and "libs" obviously depends on both. How do those two "interact" and could there be conflicts, i.e. if I added different manifest instructions?

I assume the last jar instruction called would win, am I right?

BTW a "merge files" would be great!

Martin



On Wed, May 7, 2008 at 10:49 AM, Hans Dockter <[hidden email]> wrote:
Hi Martin,

On May 6, 2008, at 10:49 AM, Hans Dockter wrote:
Hi Martin,

now the second part of my answer.

You could build your project like this:

usePlugin('java')
version = '1.0'
sourceCompatibility = 1.5targetCompatibility = 1.5
dependencies {    addFlatDirResolver('lib', file('libs'))    clientModule(['groovy'], ":groovy-all:1.6-beta-1") {        dependency(":commons-cli:1.0")    }    testCompile ":junit:4.4"}
libs.jar('myfat') {    fileSet(dir: classesDir)    AntDirective antDirective = new AntDirective()    antDirective.directive = {        zipgroupfileset(dir: new File(rootDir, 'lib'))    }    resourceCollections << antDirective    manifest.mainAttributes('Main-Class': 'org.myproject.Main')}
This is all you need. And you have dependency management which we think is something very valuable (see the chapter on dependencies). Its is not a thrilling yet I think a reasonable solution for your problem. In the next release of Gradle we want to offer a merge function where you can say:
my_jar {   merge(someJarFiles)}

the new lines got swallowed. Here a readable version:

usePlugin('java')
version = '1.0'
sourceCompatibility = 1.5
targetCompatibility = 1.5
dependencies {    
   addFlatDirResolver('lib', file('libs'))   
   clientModule(['groovy'], ":groovy-all:1.6-beta-1") {       
       dependency(":commons-cli:1.0")    
    }    
    testCompile ":junit:4.4"
}
libs.jar('myfat') {    
   fileSet(dir: classesDir)    
   AntDirective antDirective = new AntDirective()   
   antDirective.directive = {        
      zipgroupfileset(dir: new File(rootDir, 'lib'))    
   }    
   resourceCollections << antDirective    
   manifest.mainAttributes('Main-Class': 'org.myproject.Main')
}

This is all you need. And you have dependency management which we think is something very valuable (see the chapter on dependencies). Its is not a thrilling yet I think a reasonable solution for your problem. In the next release of Gradle we want to offer a merge function where you can say:

my_jar {   
   merge(someJarFiles)
}

That would be pretty nice. 

But there will be always features that are missing, It is essential that Gradle offers the flexibility to add custom behavior when there is no explicit support for a certain functionality.

We spend a lot of effort into our documentation. But the handling of archives deserves more coverage.

- Hans

P.S Here is the more or less corresponding Gant script (from Martin's mail to the Groovy user list):

// PrecheckinggroovyHome = System.getenv( ).'GROOVY_HOME'if((groovyHome == null) || (groovyHome == '')) {    println('GROOVY_HOME is not set, so a build cannot happen.')    return}

// Setup directories, mostly according to Maven/Cradle
final sourceDir = 'src/main/groovy'final libDir = 'src/lib'final buildDir = 'build'final buildClassesDir = buildDir + '/classes' final buildMetadataDir = buildClassesDir + '/META-INF'
// Setup infofinal projectName = 'Scriptcopy'final projectPackage = 'de.martinstephan'final projectMainClass = 'Scriptcopy'final projectPath = projectPackage.replace('.', '/')final jarPath = "${buildDir}/${projectName}.jar"final version = '0.1.0'
//  Set up all the targets.

includeTool << gant.tools.Execute
target(init: 'Init source directories.') {    Ant.mkdir(dir: 'src/main/groovy')} 
target(clean: 'Delete the compiled classes.') {    delete(dir: buildDir)}
Ant.taskdef(name: 'groovyc', classname: 'org.codehaus.groovy.ant.Groovyc')target(compile: 'Compile everything.' ) {    depends(clean)    Ant.mkdir(dir: buildClassesDir)    Ant.groovyc(srcdir: sourceDir , destdir: buildClassesDir)}
target(jar: 'Put everything in a jar') {    depends(compile)    Ant.jar(destfile: jarPath, compress: true, index: true ) {        fileset(dir: buildClassesDir, includes: "**/*.class")        zipgroupfileset(dir: groovyHome, includes: 'embeddable/groovy-all-*.jar')        zipgroupfileset(dir: groovyHome, includes: 'lib/commons-cli-*.jar')        //zipgroupfileset(dir: libdir, includes: '*.jar' )        // add more jars here
        manifest {            attribute(name: 'Main-Class', value: "${projectPackage}.${projectMainClass}")         }    }}
target(test: 'Test after compiling and jaring..') {    depends(jar)    Ant.java(jar: jarPath, fork: true) {        arg(value: '-s')        arg(value: 'testscript.xml')        //arg(value: '-h')    }}
target(_test: 'Test only..') {    Ant.java(jar: jarPath, fork: true) {        arg(value: '-s')        arg(value: 'testscript.xml')        //arg(value: '-h')    }}


On May 6, 2008, at 1:01 AM, Hans Dockter wrote:
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





--
Hans Dockter
Gradle Project lead





--
Hans Dockter
Gradle Project lead





Reply | Threaded
Open this post in threaded view
|

Re: Gradle Usage

hans_d
Administrator
Hi Martin,

On May 7, 2008, at 12:09 PM, Martin Stephan wrote:
Hi Hans,

thank you very much! I will play around with that and see what I can make of it.

So far I have two questions (after typing that from my smartphone screen while sitting in a train)

What's the deal with the AntDirective? Will a simple "ant.mkdir(dir:someDir) [for example] not also work? I haven't seen this in the documentation (not even the 0.1.4)

The documentation for archives hasn't been enhanced in 0.1.4. This is planned for 0.1.5.

AntDirective is not a good name. It should be called AntResource. Gradle provides its own API for assigning resources to an archive. We use the AntDirective if the Gradle API does not offer what you want (e.g. zipgroupfileset). You can pass any Ant resources via ant directives to an archive.


Also, your script creates another "myfat_jar" in addition to the existing "myclass_jar" and "libs" obviously depends on both.

I thought it makes sense to have a jar which contains only your classes and a jar which contains everything. You might want to use the lean jar for example to play with other versions of Groovy. 

How do those two "interact" and could there be conflicts, i.e. if I added different manifest instructions?

There are no conflicts. A java/groovy project has a property called manifest. Everything you assign to this manifest makes it into the manifest of every jar/war you create. At least this is the default.

In the configuration of a jar/war archive you can create additional entries for the manifest which are specific to this archive.

I have discovered a bug in regard to this. See http://jira.codehaus.org/browse/GRADLE-88

It will be fixed in 0.1.5. In the bug report there is also a workaround described.



I assume the last jar instruction called would win, am I right?

BTW a "merge files" would be great!

Definitely. It will be part of 0.1.5.

- Hans



Martin



On Wed, May 7, 2008 at 10:49 AM, Hans Dockter <[hidden email]> wrote:
Hi Martin,

On May 6, 2008, at 10:49 AM, Hans Dockter wrote:
Hi Martin,

now the second part of my answer.

You could build your project like this:

usePlugin('java')
version = '1.0'
sourceCompatibility = 1.5targetCompatibility = 1.5
dependencies {    addFlatDirResolver('lib', file('libs'))    clientModule(['groovy'], ":groovy-all:1.6-beta-1") {        dependency(":commons-cli:1.0")    }    testCompile ":junit:4.4"}
libs.jar('myfat') {    fileSet(dir: classesDir)    AntDirective antDirective = new AntDirective()    antDirective.directive = {        zipgroupfileset(dir: new File(rootDir, 'lib'))    }    resourceCollections << antDirective    manifest.mainAttributes('Main-Class': 'org.myproject.Main')}
This is all you need. And you have dependency management which we think is something very valuable (see the chapter on dependencies). Its is not a thrilling yet I think a reasonable solution for your problem. In the next release of Gradle we want to offer a merge function where you can say:
my_jar {   merge(someJarFiles)}

the new lines got swallowed. Here a readable version:

usePlugin('java')
version = '1.0'
sourceCompatibility = 1.5
targetCompatibility = 1.5
dependencies {    
   addFlatDirResolver('lib', file('libs'))   
   clientModule(['groovy'], ":groovy-all:1.6-beta-1") {       
       dependency(":commons-cli:1.0")    
    }    
    testCompile ":junit:4.4"
}
libs.jar('myfat') {    
   fileSet(dir: classesDir)    
   AntDirective antDirective = new AntDirective()   
   antDirective.directive = {        
      zipgroupfileset(dir: new File(rootDir, 'lib'))    
   }    
   resourceCollections << antDirective    
   manifest.mainAttributes('Main-Class': 'org.myproject.Main')
}

This is all you need. And you have dependency management which we think is something very valuable (see the chapter on dependencies). Its is not a thrilling yet I think a reasonable solution for your problem. In the next release of Gradle we want to offer a merge function where you can say:

my_jar {   
   merge(someJarFiles)
}

That would be pretty nice. 

But there will be always features that are missing, It is essential that Gradle offers the flexibility to add custom behavior when there is no explicit support for a certain functionality.

We spend a lot of effort into our documentation. But the handling of archives deserves more coverage.

- Hans

P.S Here is the more or less corresponding Gant script (from Martin's mail to the Groovy user list):

// PrecheckinggroovyHome = System.getenv( ).'GROOVY_HOME'if((groovyHome == null) || (groovyHome == '')) {    println('GROOVY_HOME is not set, so a build cannot happen.')    return}

// Setup directories, mostly according to Maven/Cradle
final sourceDir = 'src/main/groovy'final libDir = 'src/lib'final buildDir = 'build'final buildClassesDir = buildDir + '/classes' final buildMetadataDir = buildClassesDir + '/META-INF'
// Setup infofinal projectName = 'Scriptcopy'final projectPackage = 'de.martinstephan'final projectMainClass = 'Scriptcopy'final projectPath = projectPackage.replace('.', '/')final jarPath = "${buildDir}/${projectName}.jar"final version = '0.1.0'
//  Set up all the targets.

includeTool << gant.tools.Execute
target(init: 'Init source directories.') {    Ant.mkdir(dir: 'src/main/groovy')} 
target(clean: 'Delete the compiled classes.') {    delete(dir: buildDir)}
Ant.taskdef(name: 'groovyc', classname: 'org.codehaus.groovy.ant.Groovyc')target(compile: 'Compile everything.' ) {    depends(clean)    Ant.mkdir(dir: buildClassesDir)    Ant.groovyc(srcdir: sourceDir , destdir: buildClassesDir)}
target(jar: 'Put everything in a jar') {    depends(compile)    Ant.jar(destfile: jarPath, compress: true, index: true ) {        fileset(dir: buildClassesDir, includes: "**/*.class")        zipgroupfileset(dir: groovyHome, includes: 'embeddable/groovy-all-*.jar')        zipgroupfileset(dir: groovyHome, includes: 'lib/commons-cli-*.jar')        //zipgroupfileset(dir: libdir, includes: '*.jar' )        // add more jars here
        manifest {            attribute(name: 'Main-Class', value: "${projectPackage}.${projectMainClass}")         }    }}
target(test: 'Test after compiling and jaring..') {    depends(jar)    Ant.java(jar: jarPath, fork: true) {        arg(value: '-s')        arg(value: 'testscript.xml')        //arg(value: '-h')    }}
target(_test: 'Test only..') {    Ant.java(jar: jarPath, fork: true) {        arg(value: '-s')        arg(value: 'testscript.xml')        //arg(value: '-h')    }}


On May 6, 2008, at 1:01 AM, Hans Dockter wrote:
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





--
Hans Dockter
Gradle Project lead





--
Hans Dockter
Gradle Project lead






--
Hans Dockter
Gradle Project lead




Reply | Threaded
Open this post in threaded view
|

Re: Gradle Usage

hans_d
Administrator
In reply to this post by hans_d

On May 7, 2008, at 10:49 AM, Hans Dockter wrote:

> Hi Martin,
>
> On May 6, 2008, at 10:49 AM, Hans Dockter wrote:
>> Hi Martin,
>>
>> now the second part of my answer.
>>
>> You could build your project like this:
>>
>> usePlugin('java')
>> version = '1.0'
>> sourceCompatibility = 1.5targetCompatibility = 1.5
>> dependencies {    addFlatDirResolver('lib', file('libs'))    
>> clientModule(['groovy'], ":groovy-all:1.6-beta-1")  
>> {        dependency(":commons-cli:1.0")    }    testCompile  
>> ":junit:4.4"}
>> libs.jar('myfat') {    fileSet(dir: classesDir)    AntDirective  
>> antDirective = new AntDirective()    antDirective.directive =  
>> {        zipgroupfileset(dir: new File(rootDir, 'lib'))    }    
>> resourceCollections << antDirective    manifest.mainAttributes
>> ('Main-Class': 'org.myproject.Main')}
>> This is all you need. And you have dependency management which we  
>> think is something very valuable (see the chapter on  
>> dependencies). Its is not a thrilling yet I think a reasonable  
>> solution for your problem. In the next release of Gradle we want  
>> to offer a merge function where you can say:
>> my_jar {   merge(someJarFiles)}
>
> the new lines got swallowed. Here a readable version:
>
> usePlugin('java')
> version = '1.0'
> sourceCompatibility = 1.5
> targetCompatibility = 1.5
> dependencies {
>    addFlatDirResolver('lib', file('libs'))
>    clientModule(['groovy'], ":groovy-all:1.6-beta-1") {
>        dependency(":commons-cli:1.0")
>     }
>     testCompile ":junit:4.4"
> }
> libs.jar('myfat') {
>    fileSet(dir: classesDir)
>    AntDirective antDirective = new AntDirective()
>    antDirective.directive = {
>       zipgroupfileset(dir: new File(rootDir, 'lib'))
>    }
>    resourceCollections << antDirective
>    manifest.mainAttributes('Main-Class': 'org.myproject.Main')
> }

With Gradle 0.2 you can write:

myprojectName_jar {
    mergeGroup(file('libs'))
    manifest.mainAttributes(Main-Class: 'org.myproject.Main')
}

See user's guide 9.8.3

- Hans

>
> This is all you need. And you have dependency management which we  
> think is something very valuable (see the chapter on dependencies).  
> Its is not a thrilling yet I think a reasonable solution for your  
> problem. In the next release of Gradle we want to offer a merge  
> function where you can say:
>
> my_jar {
>    merge(someJarFiles)
> }
>>
>> That would be pretty nice.
>>
>> But there will be always features that are missing, It is  
>> essential that Gradle offers the flexibility to add custom  
>> behavior when there is no explicit support for a certain  
>> functionality.
>>
>> We spend a lot of effort into our documentation. But the handling  
>> of archives deserves more coverage.
>>
>> - Hans
>>
>> P.S Here is the more or less corresponding Gant script (from  
>> Martin's mail to the Groovy user list):
>>
>>> // PrecheckinggroovyHome = System.getenv( ).'GROOVY_HOME'if
>>> ((groovyHome == null) || (groovyHome == '')) {    println
>>> ('GROOVY_HOME is not set, so a build cannot happen.')    return}
>>>
>>> // Setup directories, mostly according to Maven/Cradle
>>> final sourceDir = 'src/main/groovy'final libDir = 'src/lib'final  
>>> buildDir = 'build'final buildClassesDir = buildDir + '/classes'  
>>> final buildMetadataDir = buildClassesDir + '/META-INF'
>>> // Setup infofinal projectName = 'Scriptcopy'final projectPackage  
>>> = 'de.martinstephan'final projectMainClass = 'Scriptcopy'final  
>>> projectPath = projectPackage.replace('.', '/')final jarPath = "$
>>> {buildDir}/${projectName}.jar"final version = '0.1.0'
>>> //  Set up all the targets.
>>>
>>> includeTool << gant.tools.Execute
>>> target(init: 'Init source directories.') {    Ant.mkdir(dir: 'src/
>>> main/groovy')}
>>> target(clean: 'Delete the compiled classes.') {    delete(dir:  
>>> buildDir)}
>>> Ant.taskdef(name: 'groovyc', classname:  
>>> 'org.codehaus.groovy.ant.Groovyc')target(compile: 'Compile  
>>> everything.' ) {    depends(clean)    Ant.mkdir(dir:  
>>> buildClassesDir)    Ant.groovyc(srcdir: sourceDir , destdir:  
>>> buildClassesDir)}
>>> target(jar: 'Put everything in a jar') {    depends(compile)    
>>> Ant.jar(destfile: jarPath, compress: true, index: true )  
>>> {        fileset(dir: buildClassesDir, includes: "**/
>>> *.class")        zipgroupfileset(dir: groovyHome, includes:  
>>> 'embeddable/groovy-all-*.jar')        zipgroupfileset(dir:  
>>> groovyHome, includes: 'lib/commons-cli-*.jar')        //
>>> zipgroupfileset(dir: libdir, includes: '*.jar' )        // add  
>>> more jars here
>>>         manifest {            attribute(name: 'Main-Class',  
>>> value: "${projectPackage}.${projectMainClass}")         }    }}
>>> target(test: 'Test after compiling and jaring..') {    depends
>>> (jar)    Ant.java(jar: jarPath, fork: true) {        arg(value: '-
>>> s')        arg(value: 'testscript.xml')        //arg(value: '-
>>> h')    }}
>>> target(_test: 'Test only..') {    Ant.java(jar: jarPath, fork:  
>>> true) {        arg(value: '-s')        arg(value:  
>>> 'testscript.xml')        //arg(value: '-h')    }}
>>>
>>
>>
>> On May 6, 2008, at 1:01 AM, Hans Dockter wrote:
>>> 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
>>>
>>>
>>>
>>>
>>
>> --
>> Hans Dockter
>> Gradle Project lead
>> http://www.gradle.org
>>
>>
>>
>>
>
> --
> Hans Dockter
> Gradle Project lead
> http://www.gradle.org
>
>
>
>

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





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

    http://xircles.codehaus.org/manage_email