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