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