« Return to Thread: Gant 0.4 - Creating a powerful DSL for building Java projects
Re: Gant 0.4 - Creating a powerful DSL for building Java projects
by Jochen Theodorou
::
Rate this Message:
Hans Dockter schrieb:
> Hi,
>
> For Gant 0.4 we want to add abstractions as known from Maven, like
> project layout, build lifecycle, dependencies, etc ...
As I was encouraging a build tool written in Groovy but never had the
time to really help with Gant I feel a bit guilty ;) Anyway I had of
course some "fantasies" about how such a tool should be and some maven
things don't fit that. One of that is the project layout and plugins. I
very much dislike the maven way of forcing people to make additional
directories for plugins that are used in the build and additional
directories to separate what the developer thought belongs together. I
guess it is no problem to help if the developer keeps a certain layout,
but he should be able to change that very easily.
My basic idea of a lifecycle that time was to have simple method calls:
def build() {
init()
compile()
test()
jar()
deploy()
}
where each method can be overwritten and add things to the lifecycle...
Now I know that will not fit, since these lifecycly methods do need
additional informations like descriptions and "task" dependencies. I
guess one diea back then was to have a set of fixed top level methods
for that like
def compile(){
meta {
description "call javac task from ant to compiles all java files"
compilation from:".java", to:".class"
}
action {
ant.javac(...)
}
}
well, something like that. meta and action would be special methods
activated depending on the phase the build is. Other methods would be
allowed too, marking normal dependencies for the task. Well that was my
idea back then.. of course with some defaults for each method so that
someone could write a class like that:
class CleanAlwaysBuild extends DefaultBuild {
def build() {
clean()
super.build()
}
}
anyway... it just got the impression that a complete rework of Gant is
on the way, so I thought I mention this again.. just ignore it if you
don't like it ;)
some comments on your points:
[...]
>> 2. We use a few exemplar projects as foci for discussing what the Gant
>> scripts should look like.
>
> I like this idea very much. The respective projects should be complex
> enough. Anybody reading this, who is responsible for a build of some
> open source project and would like to join?
>
> A friend of mine knows the nutch search engine project very well
> including its build. He says they have a complex ant based build but
> does not think there is any interest from the nutch commiters in
> changing there build. But as a guinea pig, why not. We could at least
> have a look at it.
My experience with build systems is, that people are interested in it as
long as they need one, and then very fast try to forget about it ;)
>> 3. All ideas from SCons, Waf, Rake, Rant, CMake, Maven, Ant, Buildr
>> that are useful should be considered worth "stealing".
>
> This is what open source is about, isn't it ;)
but maybe you guys should point out some things that are good. In any
case you should point out what Gant can do and what not.. I mean there
must be a reason why 0.4 should be so different... or should it be not
so different and I misunderstood something?
> Some more of my thoughts on the issue:
>
> *Project Layout:*
>
> I like the project layout used by Maven2. It is defined
> here: http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
> One thing that we might add to this, is an additional folder for
> integration tests (This is also supposed to be added with Maven 2.1).
yes, that is exactly what I have a problem with... why a java sub
directory? There is more than just java. why a filters directory? I
enver really figured out what that is useful for. having src/main and
src/test is ok... even though I would not name that directory main...
anyway. Just try to make it not too complicated to have mixed content
and a different directory structure, then all should be fine.
[...]
> *Dependency handling:*
use Ivy configured from the build script (no or optional XML)
> 3.) Transitive dependencies
is a must I would say.
> a.) Even if we support transitive dependencies* we definitely should
> offer a mechanism for disabling them.
why?
[...]
> If we don't support transitive dependencies, just for
> getting/putting dependencies to/from the repository, it might be simple
> enough not to rely on an external tool for this.
I think Ivy is not very big.
> The transitive
> dependency issue deserves a wiki page on its own. But I think the
> importance of the issue should not be overestimated.
well... it will certainly work without that feature too, you will then
have to define all jars instead of the jars you use directly.
> 4.) Snapshots and scope
> Maven introduces the concept of snapshots and scopes of dependencies. I
> would leave them out for the first iteration.
I think the idea of having scopes is a good one.. but I am sure it is
not needed at first. Of course I wouldn't do that completely like maven.
I do not like the idea of having a fixed lifecycle and using the names
and scopes form such a fixed cycle doesn't fit a lifecycle that is not
fixed. For example the idea I described above a scope could be defined
by the name of the method we are in or a list consisting of all
lifecycle method names... if a list, then you could setup a kind of
inheritance between scopes and if you need only one scope you define it
for the top level method, "build" then.
[...]
> *C**onclusions*
>
> My idea would be to implement a build system with a Maven2 project
> layout (including multiple subprojects depending on each other) and a a
> lifecycle task handling based on Gant tasks. I think having a good DSL
> for those issues would be the most important thing. On top of that a
> simple dependency handling for the first release might do. That would be
> good enough to convince many people to migrate from Ant and Maven.
> Another question is whether we should start to implement a Groovy Rake
> as a base for our build system.
why depending so much on one tool on one hand and then try to unify to
totally different tools on the other?
bye blackdrag
--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
> Hi,
>
> For Gant 0.4 we want to add abstractions as known from Maven, like
> project layout, build lifecycle, dependencies, etc ...
As I was encouraging a build tool written in Groovy but never had the
time to really help with Gant I feel a bit guilty ;) Anyway I had of
course some "fantasies" about how such a tool should be and some maven
things don't fit that. One of that is the project layout and plugins. I
very much dislike the maven way of forcing people to make additional
directories for plugins that are used in the build and additional
directories to separate what the developer thought belongs together. I
guess it is no problem to help if the developer keeps a certain layout,
but he should be able to change that very easily.
My basic idea of a lifecycle that time was to have simple method calls:
def build() {
init()
compile()
test()
jar()
deploy()
}
where each method can be overwritten and add things to the lifecycle...
Now I know that will not fit, since these lifecycly methods do need
additional informations like descriptions and "task" dependencies. I
guess one diea back then was to have a set of fixed top level methods
for that like
def compile(){
meta {
description "call javac task from ant to compiles all java files"
compilation from:".java", to:".class"
}
action {
ant.javac(...)
}
}
well, something like that. meta and action would be special methods
activated depending on the phase the build is. Other methods would be
allowed too, marking normal dependencies for the task. Well that was my
idea back then.. of course with some defaults for each method so that
someone could write a class like that:
class CleanAlwaysBuild extends DefaultBuild {
def build() {
clean()
super.build()
}
}
anyway... it just got the impression that a complete rework of Gant is
on the way, so I thought I mention this again.. just ignore it if you
don't like it ;)
some comments on your points:
[...]
>> 2. We use a few exemplar projects as foci for discussing what the Gant
>> scripts should look like.
>
> I like this idea very much. The respective projects should be complex
> enough. Anybody reading this, who is responsible for a build of some
> open source project and would like to join?
>
> A friend of mine knows the nutch search engine project very well
> including its build. He says they have a complex ant based build but
> does not think there is any interest from the nutch commiters in
> changing there build. But as a guinea pig, why not. We could at least
> have a look at it.
My experience with build systems is, that people are interested in it as
long as they need one, and then very fast try to forget about it ;)
>> 3. All ideas from SCons, Waf, Rake, Rant, CMake, Maven, Ant, Buildr
>> that are useful should be considered worth "stealing".
>
> This is what open source is about, isn't it ;)
but maybe you guys should point out some things that are good. In any
case you should point out what Gant can do and what not.. I mean there
must be a reason why 0.4 should be so different... or should it be not
so different and I misunderstood something?
> Some more of my thoughts on the issue:
>
> *Project Layout:*
>
> I like the project layout used by Maven2. It is defined
> here: http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
> One thing that we might add to this, is an additional folder for
> integration tests (This is also supposed to be added with Maven 2.1).
yes, that is exactly what I have a problem with... why a java sub
directory? There is more than just java. why a filters directory? I
enver really figured out what that is useful for. having src/main and
src/test is ok... even though I would not name that directory main...
anyway. Just try to make it not too complicated to have mixed content
and a different directory structure, then all should be fine.
[...]
> *Dependency handling:*
use Ivy configured from the build script (no or optional XML)
> 3.) Transitive dependencies
is a must I would say.
> a.) Even if we support transitive dependencies* we definitely should
> offer a mechanism for disabling them.
why?
[...]
> If we don't support transitive dependencies, just for
> getting/putting dependencies to/from the repository, it might be simple
> enough not to rely on an external tool for this.
I think Ivy is not very big.
> The transitive
> dependency issue deserves a wiki page on its own. But I think the
> importance of the issue should not be overestimated.
well... it will certainly work without that feature too, you will then
have to define all jars instead of the jars you use directly.
> 4.) Snapshots and scope
> Maven introduces the concept of snapshots and scopes of dependencies. I
> would leave them out for the first iteration.
I think the idea of having scopes is a good one.. but I am sure it is
not needed at first. Of course I wouldn't do that completely like maven.
I do not like the idea of having a fixed lifecycle and using the names
and scopes form such a fixed cycle doesn't fit a lifecycle that is not
fixed. For example the idea I described above a scope could be defined
by the name of the method we are in or a list consisting of all
lifecycle method names... if a list, then you could setup a kind of
inheritance between scopes and if you need only one scope you define it
for the top level method, "build" then.
[...]
> *C**onclusions*
>
> My idea would be to implement a build system with a Maven2 project
> layout (including multiple subprojects depending on each other) and a a
> lifecycle task handling based on Gant tasks. I think having a good DSL
> for those issues would be the most important thing. On top of that a
> simple dependency handling for the first release might do. That would be
> good enough to convince many people to migrate from Ant and Maven.
> Another question is whether we should start to implement a Groovy Rake
> as a base for our build system.
why depending so much on one tool on one hand and then try to unify to
totally different tools on the other?
bye blackdrag
--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
« Return to Thread: Gant 0.4 - Creating a powerful DSL for building Java projects
| Free embeddable forum powered by Nabble | Forum Help |
