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 <[EMAIL PROTECTED]> 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
> http://www.gradle.org
>
>
>
>
>
> --
> Hans Dockter
> Gradle Project lead
> http://www.gradle.org
>
>
>
>
>
> --
> Hans Dockter
> Gradle Project lead
> http://www.gradle.org
>
>
>
>
>
