You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Xavier Hanin <xa...@gmail.com> on 2008/01/10 15:25:26 UTC
[DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Hi,
It's been a long time since I'm thinking about this, and thought it might be
interesting to share with you and see where the idea can go.
I see many developers adopt Maven because they want a build system able to
provide common features with no effort. Most of them don't want to spend
much time writing an Ant script, or have seen or heard that maintaining Ant
build scripts is troublesome. So they choose to use Maven only because it's
easy to use for common use cases: install, write a simple pom of a few lines
or generate it using an archetype, and you're ready to compile, test and
package your new project following the Maven standard structure. They also
get dependency management for free, and with only a few more effort they
have multi module builds, and some nice features like code analysis,
coverage, and a set of report gathered in a web site. That's really nice and
that's what I like about Maven.
But Maven suffers from a lack of flexibility and robustness IMHO. And later
the same people who first adopted Maven because of its perceived ease of use
become frustrated when they need to tweek the system to their own needs or
don't understand how the release plugin work. Then some of them go back to
Ant, first having to go through a sometimes painful road to describe their
whole build system in xml, especially if they aren't Ant experts. Others try
to use new build tools like raven, buildr or others.
I really like Ant, and think it is a very good basis for robust and flexible
build systems. People with enough knowledge of Ant can write very good build
systems, testable, maintainable and adaptable. But you need to get your
hands dirty, and you need to get a good knowledge of some of the mechanisms
which can make an Ant based build system manageable: import, scripts and
scriptdef, macrodef, presetdef, and so on.
Hence I'm wondering if it wouldn't be a good idea to package a set of Ant
build files, providing all the basic features of a build system for java
projects: dependency management, compilation, testing and packaging, plus
maybe some more advanced features like code coverage and code auditing.
Multi module build support would be nice to have too. Then someone needing
only those features could simply have a build file per project mostly
consisting of a single import of the common build file provided. Some
needing more could provide plugins to the build system itself. Some needing
to tweak the system could simply override some target definitions or
properties. Others with very specific needs could simply use the build
scripts as examples or basis.
I guess most people on this list know the benefit of having such a build
system and how well it scales, and most of us already have developed such a
set of build files. But providing the basis of such a good build system well
packaged and documented could improve the Ant community IMO. With some
efforts from our community we could end up with something interesting pretty
easily. Most of us don't have much time, but we probably already have a good
basis from the build files we work with around, and if this can be done in a
community effort it could remain affordable in terms of time required.
So, what do you think? Do you think this would be useful? Would you be
interested in contributing? Do you think a new Ant sub project would be a
good fit?
Xavier
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects
Posted by Ittay Dror <it...@gmail.com>.
Dominique Devienne-2 wrote:
>
> But while I agree that having a true scripting language for Ant would
> help (OO, prototype-based, or functional, leaning towards the latter
> for Ant myself), I think it's important to remember than good builds
> are *declarative* in nature. Using a pure language, when most have
> little or no support to declare your intent, would make scripts
> unreadable.
>
>
I completely agree. I just saw that the example I gave was not posted well.
Here's another try:
So I have a project that I want to build a jar from:
<project prototype="jar_project">
<sourcePath>/path/to/sources</sourcePath>
</project>
<main>project.compile</main>
This is all declerative. What it does is create a project object, with data
member 'sourcePath' whose prototype is jar_project. Behind the scenese, the
object has a lot of methods, but the average joe does not care about them.
However, If someone wants to change the logic, he can then do that. Btw, I
think this is a lot more declarative than defining lots of targets and tasks
(these are defined by jar_project).
Thank you,
Ittay
--
View this message in context: http://www.nabble.com/-DISCUSS--EasyAnt%3A-Ant-based-pre-packaged-build-system-for-java-projects-tp14735371p16986216.html
Sent from the Ant - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Dominique Devienne <dd...@gmail.com>.
On Wed, Apr 30, 2008 at 1:19 AM, Ittay Dror <it...@gmail.com> wrote:
> The root of this is, I think, because while dealing with all this build
> logic, both frameworks refused to embrace the principals behind OOP. Both
> obviously need a backing language to actually do things and have chosen
> Java, but the front end is not OO.
Interesting thoughts Ittay. What you write meshes with
JavaScript-based dream-Ant code posted a few weeks ago by one of the
commiters (from SUN I believe), to which Stefan answered with LISP
code I think ;-) All this to say that you are not alone these lines.
But while I agree that having a true scripting language for Ant would
help (OO, prototype-based, or functional, leaning towards the latter
for Ant myself), I think it's important to remember than good builds
are *declarative* in nature. Using a pure language, when most have
little or no support to declare your intent, would make scripts
unreadable.
Lots of people argue, for good reasons too, that large Ant scripts are
already unreadable, but my point is that being *declarative* is
essential to builds in general and Ant in particular. And I'll just
stop at that ;-) --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects
Posted by Ittay Dror <it...@gmail.com>.
Gilles Scokart wrote:
>
> You should maybe have a look to buildr.
>
I did, and also raven, guilder, gant, gradle, graven and more. The thing is,
Ant is the de-facto standard, with the largest community. If we want to
finally have a system that is easy to understand and yet can build JEE
projects, this is the place to start
--
View this message in context: http://www.nabble.com/-DISCUSS--EasyAnt%3A-Ant-based-pre-packaged-build-system-for-java-projects-tp14735371p16987432.html
Sent from the Ant - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Gilles Scokart <gs...@gmail.com>.
2008/4/30 Ittay Dror <it...@gmail.com>:
>
> I've read this thread and would like to maybe try and take this discussion
> elsewhere.
>
> The way I see it is that Ant and Maven came to being in order to simplify
> building projects. The philosophy (as I see it) was either "create an xml
> file with a few lines calling some tasks" or "create an xml with a short
> configuration". Along the way, it became apparent that building a project
> involves a lot of logic and thus these two frameworks grew until now they
> are both not simple to use.
>
> The root of this is, I think, because while dealing with all this build
> logic, both frameworks refused to embrace the principals behind OOP. Both
> obviously need a backing language to actually do things and have chosen
> Java, but the front end is not OO.
>
> And now this discussion seem to try to invent new ways of accomplishing
> logic by creating a 'before' attribute or macro redefinition etc. Why?
>
> Now, creating a full blown OO language in XML will also defy the 'easy'
> purpose, mainly because XML was not designed to be a language (verbose
> syntax, no debugger, etc.).
>
> But what about prototype oriented syntax? The benefit is that there's no
> introduction of 'class' concept, modifying objects is easy.
>
> General idea is that the framework defines objects (mainly containers of
> methods == tasks). Then the user creates his own object (data), and defines
> the prototype of that object to be one of the frameworks, thus getting all
> functionality. If he wants, he can override whatever methods he wants.
> Having an object that encapsulates methods allows creating helper methods
> which can easily be overridden , without complexity.
>
> So something like:
>
> <sourcePath>/path/to/source/files</sourcePath>
>
>
> <main>object.compile</main>
>
> where 'jar_project' is defined by the framework (more like a toolkit) and
> contains methods like 'compile', 'clean', etc. It can also have
> 'create_eclipse_project' method based on the data passed to it.
>
> I hope I was clear enough.
>
> Ittay
>
> Oh, one more thing, with all this logic around, there really should be a
> better way of debugging than 'echo'. Maybe the framework can convert the XML
> code to some language for easy debugging?
>
>
You should maybe have a look to buildr.
--
Gilles Scokart
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects
Posted by Ittay Dror <it...@gmail.com>.
I've read this thread and would like to maybe try and take this discussion
elsewhere.
The way I see it is that Ant and Maven came to being in order to simplify
building projects. The philosophy (as I see it) was either "create an xml
file with a few lines calling some tasks" or "create an xml with a short
configuration". Along the way, it became apparent that building a project
involves a lot of logic and thus these two frameworks grew until now they
are both not simple to use.
The root of this is, I think, because while dealing with all this build
logic, both frameworks refused to embrace the principals behind OOP. Both
obviously need a backing language to actually do things and have chosen
Java, but the front end is not OO.
And now this discussion seem to try to invent new ways of accomplishing
logic by creating a 'before' attribute or macro redefinition etc. Why?
Now, creating a full blown OO language in XML will also defy the 'easy'
purpose, mainly because XML was not designed to be a language (verbose
syntax, no debugger, etc.).
But what about prototype oriented syntax? The benefit is that there's no
introduction of 'class' concept, modifying objects is easy.
General idea is that the framework defines objects (mainly containers of
methods == tasks). Then the user creates his own object (data), and defines
the prototype of that object to be one of the frameworks, thus getting all
functionality. If he wants, he can override whatever methods he wants.
Having an object that encapsulates methods allows creating helper methods
which can easily be overridden , without complexity.
So something like:
<sourcePath>/path/to/source/files</sourcePath>
<main>object.compile</main>
where 'jar_project' is defined by the framework (more like a toolkit) and
contains methods like 'compile', 'clean', etc. It can also have
'create_eclipse_project' method based on the data passed to it.
I hope I was clear enough.
Ittay
Oh, one more thing, with all this logic around, there really should be a
better way of debugging than 'echo'. Maybe the framework can convert the XML
code to some language for easy debugging?
Xavier Hanin wrote:
>
> Hi,
>
> It's been a long time since I'm thinking about this, and thought it might
> be
> interesting to share with you and see where the idea can go.
>
> I see many developers adopt Maven because they want a build system able to
> provide common features with no effort. Most of them don't want to spend
> much time writing an Ant script, or have seen or heard that maintaining
> Ant
> build scripts is troublesome. So they choose to use Maven only because
> it's
> easy to use for common use cases: install, write a simple pom of a few
> lines
> or generate it using an archetype, and you're ready to compile, test and
> package your new project following the Maven standard structure. They also
> get dependency management for free, and with only a few more effort they
> have multi module builds, and some nice features like code analysis,
> coverage, and a set of report gathered in a web site. That's really nice
> and
> that's what I like about Maven.
>
> But Maven suffers from a lack of flexibility and robustness IMHO. And
> later
> the same people who first adopted Maven because of its perceived ease of
> use
> become frustrated when they need to tweek the system to their own needs or
> don't understand how the release plugin work. Then some of them go back to
> Ant, first having to go through a sometimes painful road to describe their
> whole build system in xml, especially if they aren't Ant experts. Others
> try
> to use new build tools like raven, buildr or others.
>
> I really like Ant, and think it is a very good basis for robust and
> flexible
> build systems. People with enough knowledge of Ant can write very good
> build
> systems, testable, maintainable and adaptable. But you need to get your
> hands dirty, and you need to get a good knowledge of some of the
> mechanisms
> which can make an Ant based build system manageable: import, scripts and
> scriptdef, macrodef, presetdef, and so on.
>
> Hence I'm wondering if it wouldn't be a good idea to package a set of Ant
> build files, providing all the basic features of a build system for java
> projects: dependency management, compilation, testing and packaging, plus
> maybe some more advanced features like code coverage and code auditing.
> Multi module build support would be nice to have too. Then someone needing
> only those features could simply have a build file per project mostly
> consisting of a single import of the common build file provided. Some
> needing more could provide plugins to the build system itself. Some
> needing
> to tweak the system could simply override some target definitions or
> properties. Others with very specific needs could simply use the build
> scripts as examples or basis.
>
> I guess most people on this list know the benefit of having such a build
> system and how well it scales, and most of us already have developed such
> a
> set of build files. But providing the basis of such a good build system
> well
> packaged and documented could improve the Ant community IMO. With some
> efforts from our community we could end up with something interesting
> pretty
> easily. Most of us don't have much time, but we probably already have a
> good
> basis from the build files we work with around, and if this can be done in
> a
> community effort it could remain affordable in terms of time required.
>
> So, what do you think? Do you think this would be useful? Would you be
> interested in contributing? Do you think a new Ant sub project would be a
> good fit?
>
> Xavier
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/
>
>
--
View this message in context: http://www.nabble.com/-DISCUSS--EasyAnt%3A-Ant-based-pre-packaged-build-system-for-java-projects-tp14735371p16976420.html
Sent from the Ant - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Xavier Hanin <xa...@gmail.com>.
On Jan 10, 2008 10:21 PM, kermitt <he...@genesys.com> wrote:
>
> I had a look, I share the same goal but I don't like the need to compile
> class especially just to setup a task with default value. It also had a
> bit
> of black magic as you can look quickly in source as a reference.
Exactly, this is drawbacks that should be addressed IMO.
>
>
> I read your idea about interceptor I think it could be a good idea but as
> you said it requires a new ant build.
>
> To move forward quickly, the hack of the merevaik project could be reused
> to
> implement Gilles idea ( having build file in a jar) and inject ivy as I
> suggest.
>
> What do you think?
I think I share your opinion: keep things simple to get something working
pretty quickly.
But first we'd need to know where to further discuss ideas about the
project. I've started the discussion here to get feedback, and I would like
to gather more feedback here and ideas before moving forward. But then we
will need to know if this should be an Ant subproject which could be
discussed here. Or if it would better to start outside the ASF. Let's take
some time before going into too low level details.
Xavier
>
>
>
>
>
>
> Xavier Hanin wrote:
> >
> > On Jan 10, 2008 8:16 PM, kermitt <he...@genesys.com> wrote:
> >
> >>
> >> I wish we could find a way to bundle common tasks : I have more than 9
> >> templates :
> >>
> >> build-common.xml
> >> build-j2ee.xml
> >> build-war.xml
> >> build-ejb.xml
> >> build-ws.xml
> >> build-client-ws.xml
> >> build-ear.xml
> >> ...
> >>
> >> These builds just formalize my build system based on Ivy.
> >> For each project I need to sync those files which is a pain within a
> >> team.
> >> How to enforce team to use your build process, how do you easly patch,
> >> add
> >> feature. It's puzzling me. Today I need to copy paste all these files
> all
> >> over my projects.
> >>
> >> I think Ivy dictate somehow the build process as you always need to
> >> perform
> >> some tasks configure/resolve/cachepath...
> >>
> >> My common-build.xml has 9 visible targets:
> >>
> >> all -> clean , build , package , publish
> >> build -> init ivy -> resolve -> compute classpath -> do I have
> something
> >> to
> >> build ? (has dependencies changed? files ?) -> find what is the next
> >> release -> compile
> >> clean -> clean any generated files
> >> doc -> build any doc
> >> package -> make a jar
> >> publish -> get current ivy version -> publish jar on local repo
> >> share -> publish jar on integration repo
> >> release -> publish jar in test/prod repo
> >> test -> lauch unit tests
> >>
> >>
> >> I wish Ant import would support URL + jar like that :
> >>
> >> <project ...>
> >> <import
> >> url="http://repo/build.jar!common-build.xml<http://repo/build.jar%21common-build.xml>
> <http://repo/build.jar%21common-build.xml>
> >> "/>
> >> </project>
> >>
> >> As ivy became a sub project, it would make sense to have a closer
> >> integration like :
> >>
> >> <project ...>
> >> <import url="ivy://settings.xml:org/module/artifact@MyResolver" />
> >> <!--
> >> would locate the settings.xml file and seek a build-common.xml file
> using
> >> MyResolver resolver.
> >> -->
> >> </project>
> >>
> >> we could imagine deeper integration :
> >>
> >> <project ...>
> >> <import url="ivy://settings.xml:org/module/artifact@MyResolver"
> >> ivyFile="${basedir]/ivy.xml"/>
> >> <!--
> >> configure ivy / read the ivy file
> >> would map each ivy configuration to a path ( path could use a lazy
> >> resolve
> >> proxy: resolve only when it get used)
> >> would import resolved artifcat as an ant build file
> >>
> >> -->
> >> </project>
> >
> >
> > Improving the import mechanism to leverage Ivy is indeed a good idea and
> a
> > good solution to package the build system parts. I also like what has
> been
> > done in merevaik, leveraging directly the xmlns support in Ant (see the
> > comment on my blog).
> >
> > Xavier
> >
> >
> >>
> >>
> >> I think is not easy to not like maven ... but Xavier is right it's time
> >> to
> >> go a step beyond with ant+ivy
> >>
> >>
> >> So any comments on that ?
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/-DISCUSS--EasyAnt%3A-Ant-based-pre-packaged-build-system-for-java-projects-tp14735371p14741437.html
> >> Sent from the Ant - Dev mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> >> For additional commands, e-mail: dev-help@ant.apache.org
> >>
> >>
> >
> >
> > --
> > Xavier Hanin - Independent Java Consultant
> > http://xhab.blogspot.com/
> > http://ant.apache.org/ivy/
> > http://www.xoocode.org/
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/-DISCUSS--EasyAnt%3A-Ant-based-pre-packaged-build-system-for-java-projects-tp14735371p14744234.html
> Sent from the Ant - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects
Posted by kermitt <he...@genesys.com>.
I had a look, I share the same goal but I don't like the need to compile
class especially just to setup a task with default value. It also had a bit
of black magic as you can look quickly in source as a reference.
I read your idea about interceptor I think it could be a good idea but as
you said it requires a new ant build.
To move forward quickly, the hack of the merevaik project could be reused to
implement Gilles idea ( having build file in a jar) and inject ivy as I
suggest.
What do you think?
Xavier Hanin wrote:
>
> On Jan 10, 2008 8:16 PM, kermitt <he...@genesys.com> wrote:
>
>>
>> I wish we could find a way to bundle common tasks : I have more than 9
>> templates :
>>
>> build-common.xml
>> build-j2ee.xml
>> build-war.xml
>> build-ejb.xml
>> build-ws.xml
>> build-client-ws.xml
>> build-ear.xml
>> ...
>>
>> These builds just formalize my build system based on Ivy.
>> For each project I need to sync those files which is a pain within a
>> team.
>> How to enforce team to use your build process, how do you easly patch,
>> add
>> feature. It's puzzling me. Today I need to copy paste all these files all
>> over my projects.
>>
>> I think Ivy dictate somehow the build process as you always need to
>> perform
>> some tasks configure/resolve/cachepath...
>>
>> My common-build.xml has 9 visible targets:
>>
>> all -> clean , build , package , publish
>> build -> init ivy -> resolve -> compute classpath -> do I have something
>> to
>> build ? (has dependencies changed? files ?) -> find what is the next
>> release -> compile
>> clean -> clean any generated files
>> doc -> build any doc
>> package -> make a jar
>> publish -> get current ivy version -> publish jar on local repo
>> share -> publish jar on integration repo
>> release -> publish jar in test/prod repo
>> test -> lauch unit tests
>>
>>
>> I wish Ant import would support URL + jar like that :
>>
>> <project ...>
>> <import
>> url="http://repo/build.jar!common-build.xml<http://repo/build.jar%21common-build.xml>
>> "/>
>> </project>
>>
>> As ivy became a sub project, it would make sense to have a closer
>> integration like :
>>
>> <project ...>
>> <import url="ivy://settings.xml:org/module/artifact@MyResolver" />
>> <!--
>> would locate the settings.xml file and seek a build-common.xml file using
>> MyResolver resolver.
>> -->
>> </project>
>>
>> we could imagine deeper integration :
>>
>> <project ...>
>> <import url="ivy://settings.xml:org/module/artifact@MyResolver"
>> ivyFile="${basedir]/ivy.xml"/>
>> <!--
>> configure ivy / read the ivy file
>> would map each ivy configuration to a path ( path could use a lazy
>> resolve
>> proxy: resolve only when it get used)
>> would import resolved artifcat as an ant build file
>>
>> -->
>> </project>
>
>
> Improving the import mechanism to leverage Ivy is indeed a good idea and a
> good solution to package the build system parts. I also like what has been
> done in merevaik, leveraging directly the xmlns support in Ant (see the
> comment on my blog).
>
> Xavier
>
>
>>
>>
>> I think is not easy to not like maven ... but Xavier is right it's time
>> to
>> go a step beyond with ant+ivy
>>
>>
>> So any comments on that ?
>>
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/-DISCUSS--EasyAnt%3A-Ant-based-pre-packaged-build-system-for-java-projects-tp14735371p14741437.html
>> Sent from the Ant - Dev mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>>
>>
>
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/
>
>
--
View this message in context: http://www.nabble.com/-DISCUSS--EasyAnt%3A-Ant-based-pre-packaged-build-system-for-java-projects-tp14735371p14744234.html
Sent from the Ant - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Xavier Hanin <xa...@gmail.com>.
On Jan 10, 2008 8:16 PM, kermitt <he...@genesys.com> wrote:
>
> I wish we could find a way to bundle common tasks : I have more than 9
> templates :
>
> build-common.xml
> build-j2ee.xml
> build-war.xml
> build-ejb.xml
> build-ws.xml
> build-client-ws.xml
> build-ear.xml
> ...
>
> These builds just formalize my build system based on Ivy.
> For each project I need to sync those files which is a pain within a team.
> How to enforce team to use your build process, how do you easly patch,
> add
> feature. It's puzzling me. Today I need to copy paste all these files all
> over my projects.
>
> I think Ivy dictate somehow the build process as you always need to
> perform
> some tasks configure/resolve/cachepath...
>
> My common-build.xml has 9 visible targets:
>
> all -> clean , build , package , publish
> build -> init ivy -> resolve -> compute classpath -> do I have something
> to
> build ? (has dependencies changed? files ?) -> find what is the next
> release -> compile
> clean -> clean any generated files
> doc -> build any doc
> package -> make a jar
> publish -> get current ivy version -> publish jar on local repo
> share -> publish jar on integration repo
> release -> publish jar in test/prod repo
> test -> lauch unit tests
>
>
> I wish Ant import would support URL + jar like that :
>
> <project ...>
> <import url="http://repo/build.jar!common-build.xml<http://repo/build.jar%21common-build.xml>
> "/>
> </project>
>
> As ivy became a sub project, it would make sense to have a closer
> integration like :
>
> <project ...>
> <import url="ivy://settings.xml:org/module/artifact@MyResolver" />
> <!--
> would locate the settings.xml file and seek a build-common.xml file using
> MyResolver resolver.
> -->
> </project>
>
> we could imagine deeper integration :
>
> <project ...>
> <import url="ivy://settings.xml:org/module/artifact@MyResolver"
> ivyFile="${basedir]/ivy.xml"/>
> <!--
> configure ivy / read the ivy file
> would map each ivy configuration to a path ( path could use a lazy resolve
> proxy: resolve only when it get used)
> would import resolved artifcat as an ant build file
>
> -->
> </project>
Improving the import mechanism to leverage Ivy is indeed a good idea and a
good solution to package the build system parts. I also like what has been
done in merevaik, leveraging directly the xmlns support in Ant (see the
comment on my blog).
Xavier
>
>
> I think is not easy to not like maven ... but Xavier is right it's time to
> go a step beyond with ant+ivy
>
>
> So any comments on that ?
>
>
>
>
>
>
> --
> View this message in context:
> http://www.nabble.com/-DISCUSS--EasyAnt%3A-Ant-based-pre-packaged-build-system-for-java-projects-tp14735371p14741437.html
> Sent from the Ant - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects
Posted by kermitt <he...@genesys.com>.
I wish we could find a way to bundle common tasks : I have more than 9
templates :
build-common.xml
build-j2ee.xml
build-war.xml
build-ejb.xml
build-ws.xml
build-client-ws.xml
build-ear.xml
...
These builds just formalize my build system based on Ivy.
For each project I need to sync those files which is a pain within a team.
How to enforce team to use your build process, how do you easly patch, add
feature. It's puzzling me. Today I need to copy paste all these files all
over my projects.
I think Ivy dictate somehow the build process as you always need to perform
some tasks configure/resolve/cachepath...
My common-build.xml has 9 visible targets:
all -> clean , build , package , publish
build -> init ivy -> resolve -> compute classpath -> do I have something to
build ? (has dependencies changed? files ?) -> find what is the next
release -> compile
clean -> clean any generated files
doc -> build any doc
package -> make a jar
publish -> get current ivy version -> publish jar on local repo
share -> publish jar on integration repo
release -> publish jar in test/prod repo
test -> lauch unit tests
I wish Ant import would support URL + jar like that :
<project ...>
<import url="http://repo/build.jar!common-build.xml"/>
</project>
As ivy became a sub project, it would make sense to have a closer
integration like :
<project ...>
<import url="ivy://settings.xml:org/module/artifact@MyResolver" />
<!--
would locate the settings.xml file and seek a build-common.xml file using
MyResolver resolver.
-->
</project>
we could imagine deeper integration :
<project ...>
<import url="ivy://settings.xml:org/module/artifact@MyResolver"
ivyFile="${basedir]/ivy.xml"/>
<!--
configure ivy / read the ivy file
would map each ivy configuration to a path ( path could use a lazy resolve
proxy: resolve only when it get used)
would import resolved artifcat as an ant build file
-->
</project>
I think is not easy to not like maven ... but Xavier is right it's time to
go a step beyond with ant+ivy
So any comments on that ?
--
View this message in context: http://www.nabble.com/-DISCUSS--EasyAnt%3A-Ant-based-pre-packaged-build-system-for-java-projects-tp14735371p14741437.html
Sent from the Ant - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Xavier Hanin <xa...@gmail.com>.
On Jan 10, 2008 5:13 PM, Dominique Devienne <dd...@gmail.com> wrote:
> On Jan 10, 2008 8:25 AM, Xavier Hanin <xa...@gmail.com> wrote:
> > So, what do you think? Do you think this would be useful? Would you be
> > interested in contributing? Do you think a new Ant sub project would be
> a
> > good fit?
>
> I too like Ant, and in the past worked full time on doing ad-hoc
> builds for many different projects which required *a lot* of
> customization. Quite a few projects were mixed Java and C++, and a lot
> of the different teams for which I was doing builds had their own way
> of doing things, so having a standard and uniform project structure a
> la Maven was not possible (and Maven is mostly Java-only, and
> difficult to extend IMHO).
>
> Despite this diversity, I was still regularly refactoring builds to
> reuse as much as possible, and even achieved a high level of reuse,
> where a project's build was down to a custom descriptor for the
> project (I was doing my own dependency stuff before Ivy came along),
> an import, and zero or more override targets.
>
> But the cost for this common build that was supposed to be generic
> enough to work with all these diverse projects was increased
> complexity, to the point that almost no one could customize a
> project's build because of the need to have a deep understanding of
> the common build and Ant's intricacies. For example, every target from
> a normal (concrete) build had to be split into 3 in the common
> (abstract) build, to add a pre and post "hook" target to allow
> customization in the concrete build. Dealing with paths and filesets
> was complex. I don't remember all the details (it's been 2+ years),
> but I clearly remember I was "fighting" Ant, and I have a lot of
> experience with Ant.
I too sometimes feel like I'm "fighting" Ant, but I always find a solution.
And the more I learn the less I fight. But I understand your comment, and I
agree that Ant has some drawbacks that we will have to fight with while
building a resuable build system based on it. But it also has many
advantages, one of the most important IMO being its very large user base.
This means that a lot of people out there are able to understand how a well
written build script work. So if we base a build system on Ant, a very large
number of people will be able to review it and tweak it, especially in the
java community. But this won't be a silver bullet either, and I don't
foresee this system replacing Ant itself. For those having very specific
needs, I guess writing ad hoc build files will still be the solution. What
I'm targetting is the users starting projects from scratch, or people who
want to move away from Maven, or considering to move to a structured and
uniform build system.
>
> So I guess I'm saying that I agree with you on the goal, but having
> tried to achieve it myself to serve the need of the builds I was
> managing proved quite difficult, and Ant has to come a long way still
> to support what you describe IMHO. Sure, I should have tried to modify
> Ant itself to make it easier, but that's no easy task,
Agreed, but that's also why I'm discussing this on this list: here we have
all the Ant gurus (including you :)), so if we can get some of them at least
interested in the project we could even maybe tweak Ant when necessary.
and life made
> it so that my involvement with Ant took a back step, and I'm mostly
> watching from afar what's going on in Ant. I've never used Ivy for
> example. I'd probably have replaced my dependency stuff with Ivy by
> now, although my stuff was C++ aware and was pulling not just jars
> with also C++ headers and libraries, packaged sources of dependent
> modules for debugging, etc...
BTW Ivy is language agnostic, so you can use it for non java dependency
management. But this is out of topic.
>
> All the power to everyone that wants to achieve the goal of reusable
> scripts, but my own experience was quite mixed, despite the fact that
> it was successful enough to still be in use today more than 2 years
> after I'm gone, mostly untouched.
I understand, thanks for sharing your experience, I guess if the job was
*so* easy it would have already been done :-)
>
>
> I hope these words don't discourage you though!
Don't worry :-)
> But from the energy I
> can read in your posts, I don't think I could ;-) Cheers, and good
> luck, --DD
Thanks,
Xavier
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Xavier Hanin <xa...@gmail.com>.
On Jan 11, 2008 9:55 AM, Gilles Scokart <gs...@gmail.com> wrote:
> 2008/1/10, Dominique Devienne <dd...@gmail.com>:
> >
> >
> > it was successful enough to still be in use today more than 2 years
> > after I'm gone, mostly untouched.
> >
> >
> I think this is very usual. Once a build system is ok, no-one want to
> take
> the risk to change it, and often no-one can change it anymore.
>
> This is why black magic should be avoided. And this is why good
> documentation techniques are required.
>
> If you have ever maintained a generic build script written by someone else
> you probably understand what I mean.
>
> I think this is the major challenge in the build managment today. And
> that
> will be the challenge for such a project.
Agreed. IMO this is a challenge for any system. A good answer to this tough
problem is usually documentation and modularity. Modularity let divide the
tough problem is smaller parts, easier to understand and to maintain. I see
many Ant based build systems which are unmaintainable just because they
aren't modular and have a lot of duplicate code. So I think we should try to
make the build system modular, and the Ant import system already help, even
though some limitations make some things difficult as Dominique pointed out.
Another advantage of such a system over purely home made systems is that you
share knowledge of the system architecture over a community. So even if we
don't manage to make a system easy to understand, it will probably be easier
to maintain for users just because they can ask question about how the
system is built to the community who built it or is maintaining it.
Xavier
>
>
> --
> Gilles Scokart
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Gilles Scokart <gs...@gmail.com>.
2008/1/10, Dominique Devienne <dd...@gmail.com>:
>
>
> it was successful enough to still be in use today more than 2 years
> after I'm gone, mostly untouched.
>
>
I think this is very usual. Once a build system is ok, no-one want to take
the risk to change it, and often no-one can change it anymore.
This is why black magic should be avoided. And this is why good
documentation techniques are required.
If you have ever maintained a generic build script written by someone else
you probably understand what I mean.
I think this is the major challenge in the build managment today. And that
will be the challenge for such a project.
--
Gilles Scokart
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Dominique Devienne <dd...@gmail.com>.
On Jan 10, 2008 8:25 AM, Xavier Hanin <xa...@gmail.com> wrote:
> So, what do you think? Do you think this would be useful? Would you be
> interested in contributing? Do you think a new Ant sub project would be a
> good fit?
I too like Ant, and in the past worked full time on doing ad-hoc
builds for many different projects which required *a lot* of
customization. Quite a few projects were mixed Java and C++, and a lot
of the different teams for which I was doing builds had their own way
of doing things, so having a standard and uniform project structure a
la Maven was not possible (and Maven is mostly Java-only, and
difficult to extend IMHO).
Despite this diversity, I was still regularly refactoring builds to
reuse as much as possible, and even achieved a high level of reuse,
where a project's build was down to a custom descriptor for the
project (I was doing my own dependency stuff before Ivy came along),
an import, and zero or more override targets.
But the cost for this common build that was supposed to be generic
enough to work with all these diverse projects was increased
complexity, to the point that almost no one could customize a
project's build because of the need to have a deep understanding of
the common build and Ant's intricacies. For example, every target from
a normal (concrete) build had to be split into 3 in the common
(abstract) build, to add a pre and post "hook" target to allow
customization in the concrete build. Dealing with paths and filesets
was complex. I don't remember all the details (it's been 2+ years),
but I clearly remember I was "fighting" Ant, and I have a lot of
experience with Ant.
So I guess I'm saying that I agree with you on the goal, but having
tried to achieve it myself to serve the need of the builds I was
managing proved quite difficult, and Ant has to come a long way still
to support what you describe IMHO. Sure, I should have tried to modify
Ant itself to make it easier, but that's no easy task, and life made
it so that my involvement with Ant took a back step, and I'm mostly
watching from afar what's going on in Ant. I've never used Ivy for
example. I'd probably have replaced my dependency stuff with Ivy by
now, although my stuff was C++ aware and was pulling not just jars
with also C++ headers and libraries, packaged sources of dependent
modules for debugging, etc...
All the power to everyone that wants to achieve the goal of reusable
scripts, but my own experience was quite mixed, despite the fact that
it was successful enough to still be in use today more than 2 years
after I'm gone, mostly untouched.
I hope these words don't discourage you though! But from the energy I
can read in your posts, I don't think I could ;-) Cheers, and good
luck, --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Peter Arrenbrecht <pe...@gmail.com>.
On Jan 10, 2008 9:13 PM, Xavier Hanin <xa...@gmail.com> wrote:
> On Jan 10, 2008 7:21 PM, Peter Arrenbrecht <pe...@gmail.com>
> wrote:
>
> > Providing
> > override hooks is all well and good, but that is still basically the
> > very controlled and rigit maven approach, I think.
> It depends on what you accept to do in your override. If the build system
> somewhat relies on Ant import mechanism, you are able to override any
> target defined by the build system. In the end if you have something very
> specific the worst that could happen is override everything, making the
> build system useless except it first provided a structure. But at least you
> are always free, which is not the case with maven.
Then by all means let's use import. This is exactly what I meant.
> > It's like the
> > difference between an interpreter and a code generator. IIRC, in Rails
> > you normally get interpretation (on the fly code generation, in fact),
> > but you can always switch to full blown code generation which you can
> > then inspect and tweak. I think that is part of the reason for its
> > success. It makes the whole thing transparent, but let's people stick
> > to the standard where that suffices.
> Interesting comparison, not sure how it could be applied to the build system
> though.
IIRC, custom Maven steps are written in Java. You cannot look at the
provided build logic in the language you are working in to describe
your build. So Maven is an interpreter.
The envisioned Ant build template would feel more like on-the-fly code
generation (import could be thought of as inlining its stuff), with
the option of truly inling the code for tweaking.
Background on this way of looking at it:
http://peomeint.blogspot.com/2005/10/debugging-domain-specific-languages.html
-peo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Peter Arrenbrecht <pe...@gmail.com>.
On Jan 10, 2008 9:33 PM, Dominique Devienne <dd...@gmail.com> wrote:
> On Jan 10, 2008 2:13 PM, Xavier Hanin <xa...@gmail.com> wrote:
> > On Jan 10, 2008 7:21 PM, Peter Arrenbrecht <pe...@gmail.com>
> > > Providing
> > > override hooks is all well and good, but that is still basically the
> > > very controlled and rigit maven approach, I think.
> >
> > It depends on what you accept to do in your override. If the build system
> > somewhat relies on Ant import mechanism, you are able to override any
> > target defined by the build system. In the end if you have something very
> > specific the worst that could happen is override everything, making the
> > build system useless except it first provided a structure. But at least you
> > are always free, which is not the case with maven.
>
> Maven's override hooks are a good thing IMHO. The problem with Ant is
> that you have to provide them explicitly in the ''abstract'' build
> file so that the ''concrete'' build can override them, as opposed to
> Maven's hooks, where you simply define in pre-goal in the concrete
> build without any need to modify the abstract build.
>
> It's the C++ where all class methods are non-virtual by default, and
> and Java where there's virtual by default. Unless the class is
> specifically designed not to be extended, the Java way is more
> flexible because you can often intercept the virtual call and make
> your pre and post processing there. (let's not go into philosophical
> flame about the good or bad of this please)
Hmm. I was expecting the abstract build to be well designed in this
case (and yes, I believe in carefully designed overridability). But,
more importantly, if it does not suit your needs, in Ant you can just
override the import with the exact code you copy from the template,
and then tweak it. Advantages of that have been discussed further
above in this thread.
-peo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Matt Benson <gu...@yahoo.com>.
--- Xavier Hanin <xa...@gmail.com> wrote:
> On Jan 10, 2008 9:33 PM, Dominique Devienne
> <dd...@gmail.com> wrote:
>
> > On Jan 10, 2008 2:13 PM, Xavier Hanin
> <xa...@gmail.com> wrote:
> > > On Jan 10, 2008 7:21 PM, Peter Arrenbrecht
> <pe...@gmail.com>
> > > > Providing
> > > > override hooks is all well and good, but that
> is still basically the
> > > > very controlled and rigit maven approach, I
> think.
> > >
> > > It depends on what you accept to do in your
> override. If the build
> > system
> > > somewhat relies on Ant import mechanism, you are
> able to override any
> > > target defined by the build system. In the end
> if you have something
> > very
> > > specific the worst that could happen is override
> everything, making the
> > > build system useless except it first provided a
> structure. But at least
> > you
> > > are always free, which is not the case with
> maven.
> >
> > Maven's override hooks are a good thing IMHO. The
> problem with Ant is
> > that you have to provide them explicitly in the
> ''abstract'' build
> > file so that the ''concrete'' build can override
> them, as opposed to
> > Maven's hooks, where you simply define in pre-goal
> in the concrete
> > build without any need to modify the abstract
> build.
> >
> > It's the C++ where all class methods are
> non-virtual by default, and
> > and Java where there's virtual by default. Unless
> the class is
> > specifically designed not to be extended, the Java
> way is more
> > flexible because you can often intercept the
> virtual call and make
> > your pre and post processing there. (let's not go
> into philosophical
> > flame about the good or bad of this please)
> >
> > Having the ability to say in Ant <target
> before="compile"/> or <target
> > after="deploy"/> with no need to add explicit
> -pre-compile or
> > -post-deploy hooks in the base build would already
> simplify things
> > when customizing a base build, and make it more
> ''hackable''.
>
> I was thinking about something even more flexible
> based on events: <target
> on="before:compile" />. Then all you need is trigger
> events at the beginning
> and the end of each target. The problem is that
> either solutions require
> changes in Ant.
>
> Similarly, an explicit <target override="compile"/>
> to explicitly
> > completely replace a base target is better IMHO to
> the implicit
> > override that currently happens, and makes the
> build file more
> > readable/explicit about the intent. --DD
>
> True, pretty much like the @Override introduced in
> Java 5.
>
>
> > PS: The before/after target would be moot is
> <target override>
> > supported a nested <super/> element. That's a
> syntax that would flow
> > better IHMO.
>
> Yes, would be a nice improvement too. But in my mind
> I was more thinking
> about a build system based on current Ant feature
> set and syntax, at least
> for a first version. Unless several Ant committers
> would like to get
> involved and target a new Ant version to support the
> new build system.
>
> Opinions?
>
1. You yourself are an Ant committer now. ;)
2. Usually it seems we are able to do new things
without precluding the old; as long as this is the
case I don't see why you, I, we, or somebody else
can't do reasonable things to make Any more
extensible.
$0.02
-Matt
> Xavier
>
> >
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail:
> dev-help@ant.apache.org
> >
> >
>
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/
>
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Xavier Hanin <xa...@gmail.com>.
On Jan 11, 2008 6:35 AM, Stefan Bodewig <bo...@apache.org> wrote:
> "Xavier Hanin" <xa...@gmail.com> writes:
>
> > But in my mind I was more thinking about a build system based on
> > current Ant feature set and syntax,
>
> Which probably would lead to a more complex system than it needed to
> be without such a restriction.
You're right. I guess I still don't feel like a true Ant committer yet,
that's maybe why I still try to envision things which do not require changes
in Ant.
> Dominique's <super/> or something similar was among the features the
> Centipede folks wanted us to do, but that never happened. With more
> Ant committers directly involved the project you envision would have
> way more chances to succeed in influencing Ant.
Exactly. That's one of the reason why I started this discussion here :-)
>
>
> > at least for a first version.
>
> If you want to have a first release quickly, I agree.
To be honest I don't really mind about when we get the first release. This
idea does not come from a need I have on any particular project. That being
said I think one of the key of the success of good adoption is to adopt the
"release early, release often" principle. Another reason why I try to see a
very simple solution which does not require changes is that I don't have
much time to involve in the project, so by keeping things simple we get more
chance to get something actually done and working.
>
>
> > Unless several Ant committers would like to get involved and target
> > a new Ant version to support the new build system.
>
> I would like to get involved,
Great!
> but can't promise to not disapear for
> weeks like I've been doing over the past years.
I can't either. I think all of us are doing this work in our spare time, and
we don't always have spare time. But power comes from the community, and the
more people get involved, the more likely to succeed is the project IMHO.
>
> At least three other Ant committers (apart from you and me) have been
> involved in this thread so I'd say chances aren't that bad.
:-) And the rate of opinions and thoughts given in this thread is a good
sign too.
Xavier
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Stefan Bodewig <bo...@apache.org>.
"Xavier Hanin" <xa...@gmail.com> writes:
> But in my mind I was more thinking about a build system based on
> current Ant feature set and syntax,
Which probably would lead to a more complex system than it needed to
be without such a restriction.
Dominique's <super/> or something similar was among the features the
Centipede folks wanted us to do, but that never happened. With more
Ant committers directly involved the project you envision would have
way more chances to succeed in influencing Ant.
> at least for a first version.
If you want to have a first release quickly, I agree.
> Unless several Ant committers would like to get involved and target
> a new Ant version to support the new build system.
I would like to get involved, but can't promise to not disapear for
weeks like I've been doing over the past years.
At least three other Ant committers (apart from you and me) have been
involved in this thread so I'd say chances aren't that bad.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Xavier Hanin <xa...@gmail.com>.
On Jan 10, 2008 9:33 PM, Dominique Devienne <dd...@gmail.com> wrote:
> On Jan 10, 2008 2:13 PM, Xavier Hanin <xa...@gmail.com> wrote:
> > On Jan 10, 2008 7:21 PM, Peter Arrenbrecht <pe...@gmail.com>
> > > Providing
> > > override hooks is all well and good, but that is still basically the
> > > very controlled and rigit maven approach, I think.
> >
> > It depends on what you accept to do in your override. If the build
> system
> > somewhat relies on Ant import mechanism, you are able to override any
> > target defined by the build system. In the end if you have something
> very
> > specific the worst that could happen is override everything, making the
> > build system useless except it first provided a structure. But at least
> you
> > are always free, which is not the case with maven.
>
> Maven's override hooks are a good thing IMHO. The problem with Ant is
> that you have to provide them explicitly in the ''abstract'' build
> file so that the ''concrete'' build can override them, as opposed to
> Maven's hooks, where you simply define in pre-goal in the concrete
> build without any need to modify the abstract build.
>
> It's the C++ where all class methods are non-virtual by default, and
> and Java where there's virtual by default. Unless the class is
> specifically designed not to be extended, the Java way is more
> flexible because you can often intercept the virtual call and make
> your pre and post processing there. (let's not go into philosophical
> flame about the good or bad of this please)
>
> Having the ability to say in Ant <target before="compile"/> or <target
> after="deploy"/> with no need to add explicit -pre-compile or
> -post-deploy hooks in the base build would already simplify things
> when customizing a base build, and make it more ''hackable''.
I was thinking about something even more flexible based on events: <target
on="before:compile" />. Then all you need is trigger events at the beginning
and the end of each target. The problem is that either solutions require
changes in Ant.
Similarly, an explicit <target override="compile"/> to explicitly
> completely replace a base target is better IMHO to the implicit
> override that currently happens, and makes the build file more
> readable/explicit about the intent. --DD
True, pretty much like the @Override introduced in Java 5.
> PS: The before/after target would be moot is <target override>
> supported a nested <super/> element. That's a syntax that would flow
> better IHMO.
Yes, would be a nice improvement too. But in my mind I was more thinking
about a build system based on current Ant feature set and syntax, at least
for a first version. Unless several Ant committers would like to get
involved and target a new Ant version to support the new build system.
Opinions?
Xavier
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Dominique Devienne <dd...@gmail.com>.
On Jan 10, 2008 2:13 PM, Xavier Hanin <xa...@gmail.com> wrote:
> On Jan 10, 2008 7:21 PM, Peter Arrenbrecht <pe...@gmail.com>
> > Providing
> > override hooks is all well and good, but that is still basically the
> > very controlled and rigit maven approach, I think.
>
> It depends on what you accept to do in your override. If the build system
> somewhat relies on Ant import mechanism, you are able to override any
> target defined by the build system. In the end if you have something very
> specific the worst that could happen is override everything, making the
> build system useless except it first provided a structure. But at least you
> are always free, which is not the case with maven.
Maven's override hooks are a good thing IMHO. The problem with Ant is
that you have to provide them explicitly in the ''abstract'' build
file so that the ''concrete'' build can override them, as opposed to
Maven's hooks, where you simply define in pre-goal in the concrete
build without any need to modify the abstract build.
It's the C++ where all class methods are non-virtual by default, and
and Java where there's virtual by default. Unless the class is
specifically designed not to be extended, the Java way is more
flexible because you can often intercept the virtual call and make
your pre and post processing there. (let's not go into philosophical
flame about the good or bad of this please)
Having the ability to say in Ant <target before="compile"/> or <target
after="deploy"/> with no need to add explicit -pre-compile or
-post-deploy hooks in the base build would already simplify things
when customizing a base build, and make it more ''hackable''.
Similarly, an explicit <target override="compile"/> to explicitly
completely replace a base target is better IMHO to the implicit
override that currently happens, and makes the build file more
readable/explicit about the intent. --DD
PS: The before/after target would be moot is <target override>
supported a nested <super/> element. That's a syntax that would flow
better IHMO.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Xavier Hanin <xa...@gmail.com>.
On Jan 10, 2008 7:21 PM, Peter Arrenbrecht <pe...@gmail.com>
wrote:
> I like the idea very much. One crucial aspect, however, would be to
> provide a graceful path from using the prepackaged building blocks
> towards inlining and customizing them. If this is not possible, the
> thing will most likely start feeling as unwieldy as maven itself in a
> while. The advantage of ant would really come into play when users can
> pull in the building blocks and immediately see how everything was
> done, learn from that, and then tweak to their liking.
Exactly.
> Providing
> override hooks is all well and good, but that is still basically the
> very controlled and rigit maven approach, I think.
It depends on what you accept to do in your override. If the build system
somewhat relies on Ant import mechanism, you are able to override any
target defined by the build system. In the end if you have something very
specific the worst that could happen is override everything, making the
build system useless except it first provided a structure. But at least you
are always free, which is not the case with maven.
It's like the
> difference between an interpreter and a code generator. IIRC, in Rails
> you normally get interpretation (on the fly code generation, in fact),
> but you can always switch to full blown code generation which you can
> then inspect and tweak. I think that is part of the reason for its
> success. It makes the whole thing transparent, but let's people stick
> to the standard where that suffices.
Interesting comparison, not sure how it could be applied to the build system
though.
Xavier
>
>
> -peo
>
> On Jan 10, 2008 3:25 PM, Xavier Hanin <xa...@gmail.com> wrote:
> > Hi,
> >
> > It's been a long time since I'm thinking about this, and thought it
> might be
> > interesting to share with you and see where the idea can go.
> >
> > I see many developers adopt Maven because they want a build system able
> to
> > provide common features with no effort. Most of them don't want to spend
> > much time writing an Ant script, or have seen or heard that maintaining
> Ant
> > build scripts is troublesome. So they choose to use Maven only because
> it's
> > easy to use for common use cases: install, write a simple pom of a few
> lines
> > or generate it using an archetype, and you're ready to compile, test and
> > package your new project following the Maven standard structure. They
> also
> > get dependency management for free, and with only a few more effort they
> > have multi module builds, and some nice features like code analysis,
> > coverage, and a set of report gathered in a web site. That's really nice
> and
> > that's what I like about Maven.
> >
> > But Maven suffers from a lack of flexibility and robustness IMHO. And
> later
> > the same people who first adopted Maven because of its perceived ease of
> use
> > become frustrated when they need to tweek the system to their own needs
> or
> > don't understand how the release plugin work. Then some of them go back
> to
> > Ant, first having to go through a sometimes painful road to describe
> their
> > whole build system in xml, especially if they aren't Ant experts. Others
> try
> > to use new build tools like raven, buildr or others.
> >
> > I really like Ant, and think it is a very good basis for robust and
> flexible
> > build systems. People with enough knowledge of Ant can write very good
> build
> > systems, testable, maintainable and adaptable. But you need to get your
> > hands dirty, and you need to get a good knowledge of some of the
> mechanisms
> > which can make an Ant based build system manageable: import, scripts and
> > scriptdef, macrodef, presetdef, and so on.
> >
> > Hence I'm wondering if it wouldn't be a good idea to package a set of
> Ant
> > build files, providing all the basic features of a build system for java
> > projects: dependency management, compilation, testing and packaging,
> plus
> > maybe some more advanced features like code coverage and code auditing.
> > Multi module build support would be nice to have too. Then someone
> needing
> > only those features could simply have a build file per project mostly
> > consisting of a single import of the common build file provided. Some
> > needing more could provide plugins to the build system itself. Some
> needing
> > to tweak the system could simply override some target definitions or
> > properties. Others with very specific needs could simply use the build
> > scripts as examples or basis.
> >
> > I guess most people on this list know the benefit of having such a build
> > system and how well it scales, and most of us already have developed
> such a
> > set of build files. But providing the basis of such a good build system
> well
> > packaged and documented could improve the Ant community IMO. With some
> > efforts from our community we could end up with something interesting
> pretty
> > easily. Most of us don't have much time, but we probably already have a
> good
> > basis from the build files we work with around, and if this can be done
> in a
> > community effort it could remain affordable in terms of time required.
> >
> > So, what do you think? Do you think this would be useful? Would you be
> > interested in contributing? Do you think a new Ant sub project would be
> a
> > good fit?
> >
> > Xavier
> > --
> > Xavier Hanin - Independent Java Consultant
> > http://xhab.blogspot.com/
> > http://ant.apache.org/ivy/
> > http://www.xoocode.org/
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Peter Arrenbrecht <pe...@gmail.com>.
I like the idea very much. One crucial aspect, however, would be to
provide a graceful path from using the prepackaged building blocks
towards inlining and customizing them. If this is not possible, the
thing will most likely start feeling as unwieldy as maven itself in a
while. The advantage of ant would really come into play when users can
pull in the building blocks and immediately see how everything was
done, learn from that, and then tweak to their liking. Providing
override hooks is all well and good, but that is still basically the
very controlled and rigit maven approach, I think. It's like the
difference between an interpreter and a code generator. IIRC, in Rails
you normally get interpretation (on the fly code generation, in fact),
but you can always switch to full blown code generation which you can
then inspect and tweak. I think that is part of the reason for its
success. It makes the whole thing transparent, but let's people stick
to the standard where that suffices.
-peo
On Jan 10, 2008 3:25 PM, Xavier Hanin <xa...@gmail.com> wrote:
> Hi,
>
> It's been a long time since I'm thinking about this, and thought it might be
> interesting to share with you and see where the idea can go.
>
> I see many developers adopt Maven because they want a build system able to
> provide common features with no effort. Most of them don't want to spend
> much time writing an Ant script, or have seen or heard that maintaining Ant
> build scripts is troublesome. So they choose to use Maven only because it's
> easy to use for common use cases: install, write a simple pom of a few lines
> or generate it using an archetype, and you're ready to compile, test and
> package your new project following the Maven standard structure. They also
> get dependency management for free, and with only a few more effort they
> have multi module builds, and some nice features like code analysis,
> coverage, and a set of report gathered in a web site. That's really nice and
> that's what I like about Maven.
>
> But Maven suffers from a lack of flexibility and robustness IMHO. And later
> the same people who first adopted Maven because of its perceived ease of use
> become frustrated when they need to tweek the system to their own needs or
> don't understand how the release plugin work. Then some of them go back to
> Ant, first having to go through a sometimes painful road to describe their
> whole build system in xml, especially if they aren't Ant experts. Others try
> to use new build tools like raven, buildr or others.
>
> I really like Ant, and think it is a very good basis for robust and flexible
> build systems. People with enough knowledge of Ant can write very good build
> systems, testable, maintainable and adaptable. But you need to get your
> hands dirty, and you need to get a good knowledge of some of the mechanisms
> which can make an Ant based build system manageable: import, scripts and
> scriptdef, macrodef, presetdef, and so on.
>
> Hence I'm wondering if it wouldn't be a good idea to package a set of Ant
> build files, providing all the basic features of a build system for java
> projects: dependency management, compilation, testing and packaging, plus
> maybe some more advanced features like code coverage and code auditing.
> Multi module build support would be nice to have too. Then someone needing
> only those features could simply have a build file per project mostly
> consisting of a single import of the common build file provided. Some
> needing more could provide plugins to the build system itself. Some needing
> to tweak the system could simply override some target definitions or
> properties. Others with very specific needs could simply use the build
> scripts as examples or basis.
>
> I guess most people on this list know the benefit of having such a build
> system and how well it scales, and most of us already have developed such a
> set of build files. But providing the basis of such a good build system well
> packaged and documented could improve the Ant community IMO. With some
> efforts from our community we could end up with something interesting pretty
> easily. Most of us don't have much time, but we probably already have a good
> basis from the build files we work with around, and if this can be done in a
> community effort it could remain affordable in terms of time required.
>
> So, what do you think? Do you think this would be useful? Would you be
> interested in contributing? Do you think a new Ant sub project would be a
> good fit?
>
> Xavier
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Xavier Hanin <xa...@gmail.com>.
On Feb 11, 2008 8:35 PM, limbicsystem <li...@gmail.com> wrote:
>
> What Xavier is describing is exactly what I thought Maven should have
> been- a
> standard way to lay out projects, with Ant underneath to use as needed.
> And
> once your projects become non-trivial there is always the "as needed"
> part.
>
> We spent a long painful month trying to move from Maven1 to Maven2, and
> ultimately gave up. We quickly grew tired of trying to write plugins to
> handle things that would have othewise been 5 lines of Ant (or things that
> worked in M1 but no longer work in M2). Not to bash Maven, but things
> become really hard once you move outside the lines a little bit. Then on
> the other extreme you have Ant- complete freedom to do things are you see
> fit, but there is not much in the way of standards or guidelines. There
> ought to be a middle ground here somewhere.
>
> We're currently in the process standardizing on a common set of Ant
> scripts
> that get imported, using Ivy for dependency management. I can tell you-
> things become a LOT simpler once you get a few common use cases worked
> out,
> and just refer to them from each project's build.xml.
>
> In general we are following the Maven directory model, so things are laid
> out like:
>
> src/
> main/
> java/
> resources/
>
> test/
> java/
> resources/
>
> webapp/
> WEB-INF
>
>
> Things generated by the build (classes, artifacts, etc) get built in
> "target". A build.xml for a simple jar project is about 5 lines of
> boilerplate:
>
> <project basedir="." default="package" name="my-project">
> <property name="org" value="my-org"/>
> <import file="../../../../common/antbuild/common-build.xml"/>
> <target depends="jar" name="package"/>
> </project>
>
> Dependencies are external in ivy.xml, but that's all that's need to
> resolve
> dependencies, compile, test, package and deploy this project. War and Ear
> projects are not much more complicated than this either. I would very much
> like to discuss this idea, and hear what others are doing.
This is the kind of build I sometimes help to build for my customers, or
just recommend. It's based on this experience that I've suggested EasyAnt.
>From what I've been said in the discussion, it seems that to do something
that scales well to a community (an open source build system where many can
contribute is very different from an enterprise made build system) we'd need
to introduce some new concepts in Ant. I've tried to setup a small POC of
how I see this build system, to gather some feedback and continue the
discussion. I've just uploaded a new version of this POC here:
http://people.apache.org/~xavier/easyant-POC-0.2.zip
There's a README at the zip root, explaining how to try it and how it works.
I'd appreciate any feedback.
Xavier
>
>
> George
>
>
>
>
>
>
>
>
> Xavier Hanin wrote:
> >
> > Hi,
> >
> > It's been a long time since I'm thinking about this, and thought it
> might
> > be
> > interesting to share with you and see where the idea can go.
> >
> > I see many developers adopt Maven because they want a build system able
> to
> > provide common features with no effort. Most of them don't want to spend
> > much time writing an Ant script, or have seen or heard that maintaining
> > Ant
> > build scripts is troublesome. So they choose to use Maven only because
> > it's
> > easy to use for common use cases: install, write a simple pom of a few
> > lines
> > or generate it using an archetype, and you're ready to compile, test and
> > package your new project following the Maven standard structure. They
> also
> > get dependency management for free, and with only a few more effort they
> > have multi module builds, and some nice features like code analysis,
> > coverage, and a set of report gathered in a web site. That's really nice
> > and
> > that's what I like about Maven.
> >
> > But Maven suffers from a lack of flexibility and robustness IMHO. And
> > later
> > the same people who first adopted Maven because of its perceived ease of
> > use
> > become frustrated when they need to tweek the system to their own needs
> or
> > don't understand how the release plugin work. Then some of them go back
> to
> > Ant, first having to go through a sometimes painful road to describe
> their
> > whole build system in xml, especially if they aren't Ant experts. Others
> > try
> > to use new build tools like raven, buildr or others.
> >
> > I really like Ant, and think it is a very good basis for robust and
> > flexible
> > build systems. People with enough knowledge of Ant can write very good
> > build
> > systems, testable, maintainable and adaptable. But you need to get your
> > hands dirty, and you need to get a good knowledge of some of the
> > mechanisms
> > which can make an Ant based build system manageable: import, scripts and
> > scriptdef, macrodef, presetdef, and so on.
> >
> > Hence I'm wondering if it wouldn't be a good idea to package a set of
> Ant
> > build files, providing all the basic features of a build system for java
> > projects: dependency management, compilation, testing and packaging,
> plus
> > maybe some more advanced features like code coverage and code auditing.
> > Multi module build support would be nice to have too. Then someone
> needing
> > only those features could simply have a build file per project mostly
> > consisting of a single import of the common build file provided. Some
> > needing more could provide plugins to the build system itself. Some
> > needing
> > to tweak the system could simply override some target definitions or
> > properties. Others with very specific needs could simply use the build
> > scripts as examples or basis.
> >
> > I guess most people on this list know the benefit of having such a build
> > system and how well it scales, and most of us already have developed
> such
> > a
> > set of build files. But providing the basis of such a good build system
> > well
> > packaged and documented could improve the Ant community IMO. With some
> > efforts from our community we could end up with something interesting
> > pretty
> > easily. Most of us don't have much time, but we probably already have a
> > good
> > basis from the build files we work with around, and if this can be done
> in
> > a
> > community effort it could remain affordable in terms of time required.
> >
> > So, what do you think? Do you think this would be useful? Would you be
> > interested in contributing? Do you think a new Ant sub project would be
> a
> > good fit?
> >
> > Xavier
> > --
> > Xavier Hanin - Independent Java Consultant
> > http://xhab.blogspot.com/
> > http://ant.apache.org/ivy/
> > http://www.xoocode.org/
> >
> >
>
>
> --
> View this message in context:
> http://www.nabble.com/-DISCUSS--EasyAnt%3A-Ant-based-pre-packaged-build-system-for-java-projects-tp14735371p15418993.html
> Sent from the Ant - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Gilles Scokart <gs...@gmail.com>.
2008/2/11, limbicsystem <li...@gmail.com>:
>
>
> We spent a long painful month trying to move from Maven1 to Maven2, and
> ultimately gave up. We quickly grew tired of trying to write plugins to
> handle things that would have othewise been 5 lines of Ant (or things that
> worked in M1 but no longer work in M2).
Did you know you can write your plugin using ant :
http://maven.apache.org/guides/plugin/guide-ant-plugin-development.html
--
Gilles Scokart
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects
Posted by limbicsystem <li...@gmail.com>.
What Xavier is describing is exactly what I thought Maven should have been- a
standard way to lay out projects, with Ant underneath to use as needed. And
once your projects become non-trivial there is always the "as needed" part.
We spent a long painful month trying to move from Maven1 to Maven2, and
ultimately gave up. We quickly grew tired of trying to write plugins to
handle things that would have othewise been 5 lines of Ant (or things that
worked in M1 but no longer work in M2). Not to bash Maven, but things
become really hard once you move outside the lines a little bit. Then on
the other extreme you have Ant- complete freedom to do things are you see
fit, but there is not much in the way of standards or guidelines. There
ought to be a middle ground here somewhere.
We're currently in the process standardizing on a common set of Ant scripts
that get imported, using Ivy for dependency management. I can tell you-
things become a LOT simpler once you get a few common use cases worked out,
and just refer to them from each project's build.xml.
In general we are following the Maven directory model, so things are laid
out like:
src/
main/
java/
resources/
test/
java/
resources/
webapp/
WEB-INF
Things generated by the build (classes, artifacts, etc) get built in
"target". A build.xml for a simple jar project is about 5 lines of
boilerplate:
<project basedir="." default="package" name="my-project">
<property name="org" value="my-org"/>
<import file="../../../../common/antbuild/common-build.xml"/>
<target depends="jar" name="package"/>
</project>
Dependencies are external in ivy.xml, but that's all that's need to resolve
dependencies, compile, test, package and deploy this project. War and Ear
projects are not much more complicated than this either. I would very much
like to discuss this idea, and hear what others are doing.
George
Xavier Hanin wrote:
>
> Hi,
>
> It's been a long time since I'm thinking about this, and thought it might
> be
> interesting to share with you and see where the idea can go.
>
> I see many developers adopt Maven because they want a build system able to
> provide common features with no effort. Most of them don't want to spend
> much time writing an Ant script, or have seen or heard that maintaining
> Ant
> build scripts is troublesome. So they choose to use Maven only because
> it's
> easy to use for common use cases: install, write a simple pom of a few
> lines
> or generate it using an archetype, and you're ready to compile, test and
> package your new project following the Maven standard structure. They also
> get dependency management for free, and with only a few more effort they
> have multi module builds, and some nice features like code analysis,
> coverage, and a set of report gathered in a web site. That's really nice
> and
> that's what I like about Maven.
>
> But Maven suffers from a lack of flexibility and robustness IMHO. And
> later
> the same people who first adopted Maven because of its perceived ease of
> use
> become frustrated when they need to tweek the system to their own needs or
> don't understand how the release plugin work. Then some of them go back to
> Ant, first having to go through a sometimes painful road to describe their
> whole build system in xml, especially if they aren't Ant experts. Others
> try
> to use new build tools like raven, buildr or others.
>
> I really like Ant, and think it is a very good basis for robust and
> flexible
> build systems. People with enough knowledge of Ant can write very good
> build
> systems, testable, maintainable and adaptable. But you need to get your
> hands dirty, and you need to get a good knowledge of some of the
> mechanisms
> which can make an Ant based build system manageable: import, scripts and
> scriptdef, macrodef, presetdef, and so on.
>
> Hence I'm wondering if it wouldn't be a good idea to package a set of Ant
> build files, providing all the basic features of a build system for java
> projects: dependency management, compilation, testing and packaging, plus
> maybe some more advanced features like code coverage and code auditing.
> Multi module build support would be nice to have too. Then someone needing
> only those features could simply have a build file per project mostly
> consisting of a single import of the common build file provided. Some
> needing more could provide plugins to the build system itself. Some
> needing
> to tweak the system could simply override some target definitions or
> properties. Others with very specific needs could simply use the build
> scripts as examples or basis.
>
> I guess most people on this list know the benefit of having such a build
> system and how well it scales, and most of us already have developed such
> a
> set of build files. But providing the basis of such a good build system
> well
> packaged and documented could improve the Ant community IMO. With some
> efforts from our community we could end up with something interesting
> pretty
> easily. Most of us don't have much time, but we probably already have a
> good
> basis from the build files we work with around, and if this can be done in
> a
> community effort it could remain affordable in terms of time required.
>
> So, what do you think? Do you think this would be useful? Would you be
> interested in contributing? Do you think a new Ant sub project would be a
> good fit?
>
> Xavier
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/
>
>
--
View this message in context: http://www.nabble.com/-DISCUSS--EasyAnt%3A-Ant-based-pre-packaged-build-system-for-java-projects-tp14735371p15418993.html
Sent from the Ant - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects
Posted by kkckkc <kk...@gmail.com>.
A year ago I started implemented something with similar ideas. The idea
is to describe your module metadata in a separate file and provide
ant tasks to process that data. It supports multi-module builds and
it also supports fetching dependencies from maven repositories.
A module might be described similar to
<module-definition name="sample2" type="jar">
<libraries>
<library id="library">
<jar id="lib/test.jar" />
</library>
</libraries>
<build-path>
<source id="src/main/java" destination="target/classes"
bundle="true" export="true" />
<module id="core" />
<maven id="test" group-id="test" version="1.0" />
<jar id="lib/common.jar" />
<library-ref id="library" />
</build-path>
<properties>
<property key="test" value="test value" />
</properties>
</module-definition>
A few tasks are available to read this data but unfortunately there isn't a
lot
of documentation.
There is a master build.xml file at
http://code.google.com/p/common-ant-project-model/source/browse/trunk/common-ant-project-model/trunk/src/main/resources/_build.xml
that uses this metadata to provide common build functionality.
I haven't had enough time to spend on the project for the last couple of
months, but
I have used it successfully for a couple of private projects.
It is available at http://code.google.com/p/common-ant-project-model/
/Magnus
--
View this message in context: http://www.nabble.com/-DISCUSS--EasyAnt%3A-Ant-based-pre-packaged-build-system-for-java-projects-tp14735371p15432374.html
Sent from the Ant - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Xavier Hanin <xa...@gmail.com>.
On Jan 10, 2008 4:12 PM, Matt Benson <gu...@yahoo.com> wrote:
> Xavier:
> I think it would be good to have a system that
> pretty much bundles alternatives for everything Maven
> provides, but without all the black magic that makes
> Maven difficult to customize. Basically antlibs for
> all parts of the Maven lifecycle, including,
> especially, Ivy. :)
That's exactly what I'm thinking about :-)
> In fact, I already came up with
> my own name for this concept some time back:
> "Shaven". ;)
Funny :-)
Xavier
>
>
> -Matt
>
> --- Xavier Hanin <xa...@gmail.com> wrote:
>
> > Hi,
> >
> > It's been a long time since I'm thinking about this,
> > and thought it might be
> > interesting to share with you and see where the idea
> > can go.
> >
> > I see many developers adopt Maven because they want
> > a build system able to
> > provide common features with no effort. Most of them
> > don't want to spend
> > much time writing an Ant script, or have seen or
> > heard that maintaining Ant
> > build scripts is troublesome. So they choose to use
> > Maven only because it's
> > easy to use for common use cases: install, write a
> > simple pom of a few lines
> > or generate it using an archetype, and you're ready
> > to compile, test and
> > package your new project following the Maven
> > standard structure. They also
> > get dependency management for free, and with only a
> > few more effort they
> > have multi module builds, and some nice features
> > like code analysis,
> > coverage, and a set of report gathered in a web
> > site. That's really nice and
> > that's what I like about Maven.
> >
> > But Maven suffers from a lack of flexibility and
> > robustness IMHO. And later
> > the same people who first adopted Maven because of
> > its perceived ease of use
> > become frustrated when they need to tweek the system
> > to their own needs or
> > don't understand how the release plugin work. Then
> > some of them go back to
> > Ant, first having to go through a sometimes painful
> > road to describe their
> > whole build system in xml, especially if they aren't
> > Ant experts. Others try
> > to use new build tools like raven, buildr or others.
> >
> > I really like Ant, and think it is a very good basis
> > for robust and flexible
> > build systems. People with enough knowledge of Ant
> > can write very good build
> > systems, testable, maintainable and adaptable. But
> > you need to get your
> > hands dirty, and you need to get a good knowledge of
> > some of the mechanisms
> > which can make an Ant based build system manageable:
> > import, scripts and
> > scriptdef, macrodef, presetdef, and so on.
> >
> > Hence I'm wondering if it wouldn't be a good idea to
> > package a set of Ant
> > build files, providing all the basic features of a
> > build system for java
> > projects: dependency management, compilation,
> > testing and packaging, plus
> > maybe some more advanced features like code coverage
> > and code auditing.
> > Multi module build support would be nice to have
> > too. Then someone needing
> > only those features could simply have a build file
> > per project mostly
> > consisting of a single import of the common build
> > file provided. Some
> > needing more could provide plugins to the build
> > system itself. Some needing
> > to tweak the system could simply override some
> > target definitions or
> > properties. Others with very specific needs could
> > simply use the build
> > scripts as examples or basis.
> >
> > I guess most people on this list know the benefit of
> > having such a build
> > system and how well it scales, and most of us
> > already have developed such a
> > set of build files. But providing the basis of such
> > a good build system well
> > packaged and documented could improve the Ant
> > community IMO. With some
> > efforts from our community we could end up with
> > something interesting pretty
> > easily. Most of us don't have much time, but we
> > probably already have a good
> > basis from the build files we work with around, and
> > if this can be done in a
> > community effort it could remain affordable in terms
> > of time required.
> >
> > So, what do you think? Do you think this would be
> > useful? Would you be
> > interested in contributing? Do you think a new Ant
> > sub project would be a
> > good fit?
> >
> > Xavier
> > --
> > Xavier Hanin - Independent Java Consultant
> > http://xhab.blogspot.com/
> > http://ant.apache.org/ivy/
> > http://www.xoocode.org/
> >
>
>
>
>
> ____________________________________________________________________________________
> Never miss a thing. Make Yahoo your home page.
> http://www.yahoo.com/r/hs
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Xavier Hanin <xa...@gmail.com>.
FYI I've cross posted my e-mail as a post on my blog:
http://xhab.blogspot.com/2008/01/easyant-ant-based-pre-packaged-build.html
And karenin commented with a link to his light POC of a build system very
similar to what we are discussing here:
http://code.google.com/p/merevaik/
I hope karenin will join the discussion, I think he has a very neat way of
packaging the build files (at least similar to what you suggest Gilles).
As I say on my comment on my blog, there's one thing I fear with such
packaging system: they somewhat hide the information on the build files
used. And I think people who maintain build system like to see how the build
system works, and since most people are proficient with Ant, I think giving
easy access to the build files sources is important to avoid any "black
magic". But there are solutions to provide both good packaging and easy
reading.
Xavier
On Jan 10, 2008 4:36 PM, Gilles Scokart <gs...@gmail.com> wrote:
> I already thinked to something similar as well (after having re-written a
> few time generic build scripts).
>
> For me, one of the issues to solve is the problem of packaging a set of
> reusable build script in a nice way. For that,
> my idea was to use a "BAR" (Builder Archive). That would be a packaged jar
> that would include a build script with the
> life cycle, and some standard 'plug-in' builds scripts extending the life
> cycle in a standard way, (and potentally also
> the class for some task). That way, all you need to build is ant, the
> bar, and your project build script that would set
> some properties and include the right build files coming from the bar.
>
> An other difficulty is to document those reusable build scripts. I have
> already re-written a few reusable build
> scripts, but I have to admit that I never managed to get the right level
> of documentation for it.
>
> Finally, I stopped my reflections, thinking that it is certainly something
> that already exists in the wild. Does it?
>
> Gilles
>
> > -----Original Message-----
> > From: Matt Benson [mailto:gudnabrsam@yahoo.com]
> > Sent: jeudi 10 janvier 2008 16:12
> > To: Ant Developers List
> > Subject: Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for
> java projects
> >
> > Xavier:
> > I think it would be good to have a system that
> > pretty much bundles alternatives for everything Maven
> > provides, but without all the black magic that makes
> > Maven difficult to customize. Basically antlibs for
> > all parts of the Maven lifecycle, including,
> > especially, Ivy. :) In fact, I already came up with
> > my own name for this concept some time back:
> > "Shaven". ;)
> >
> > -Matt
> >
> > --- Xavier Hanin <xa...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > It's been a long time since I'm thinking about this,
> > > and thought it might be
> > > interesting to share with you and see where the idea
> > > can go.
> > >
> > > I see many developers adopt Maven because they want
> > > a build system able to
> > > provide common features with no effort. Most of them
> > > don't want to spend
> > > much time writing an Ant script, or have seen or
> > > heard that maintaining Ant
> > > build scripts is troublesome. So they choose to use
> > > Maven only because it's
> > > easy to use for common use cases: install, write a
> > > simple pom of a few lines
> > > or generate it using an archetype, and you're ready
> > > to compile, test and
> > > package your new project following the Maven
> > > standard structure. They also
> > > get dependency management for free, and with only a
> > > few more effort they
> > > have multi module builds, and some nice features
> > > like code analysis,
> > > coverage, and a set of report gathered in a web
> > > site. That's really nice and
> > > that's what I like about Maven.
> > >
> > > But Maven suffers from a lack of flexibility and
> > > robustness IMHO. And later
> > > the same people who first adopted Maven because of
> > > its perceived ease of use
> > > become frustrated when they need to tweek the system
> > > to their own needs or
> > > don't understand how the release plugin work. Then
> > > some of them go back to
> > > Ant, first having to go through a sometimes painful
> > > road to describe their
> > > whole build system in xml, especially if they aren't
> > > Ant experts. Others try
> > > to use new build tools like raven, buildr or others.
> > >
> > > I really like Ant, and think it is a very good basis
> > > for robust and flexible
> > > build systems. People with enough knowledge of Ant
> > > can write very good build
> > > systems, testable, maintainable and adaptable. But
> > > you need to get your
> > > hands dirty, and you need to get a good knowledge of
> > > some of the mechanisms
> > > which can make an Ant based build system manageable:
> > > import, scripts and
> > > scriptdef, macrodef, presetdef, and so on.
> > >
> > > Hence I'm wondering if it wouldn't be a good idea to
> > > package a set of Ant
> > > build files, providing all the basic features of a
> > > build system for java
> > > projects: dependency management, compilation,
> > > testing and packaging, plus
> > > maybe some more advanced features like code coverage
> > > and code auditing.
> > > Multi module build support would be nice to have
> > > too. Then someone needing
> > > only those features could simply have a build file
> > > per project mostly
> > > consisting of a single import of the common build
> > > file provided. Some
> > > needing more could provide plugins to the build
> > > system itself. Some needing
> > > to tweak the system could simply override some
> > > target definitions or
> > > properties. Others with very specific needs could
> > > simply use the build
> > > scripts as examples or basis.
> > >
> > > I guess most people on this list know the benefit of
> > > having such a build
> > > system and how well it scales, and most of us
> > > already have developed such a
> > > set of build files. But providing the basis of such
> > > a good build system well
> > > packaged and documented could improve the Ant
> > > community IMO. With some
> > > efforts from our community we could end up with
> > > something interesting pretty
> > > easily. Most of us don't have much time, but we
> > > probably already have a good
> > > basis from the build files we work with around, and
> > > if this can be done in a
> > > community effort it could remain affordable in terms
> > > of time required.
> > >
> > > So, what do you think? Do you think this would be
> > > useful? Would you be
> > > interested in contributing? Do you think a new Ant
> > > sub project would be a
> > > good fit?
> > >
> > > Xavier
> > > --
> > > Xavier Hanin - Independent Java Consultant
> > > http://xhab.blogspot.com/
> > > http://ant.apache.org/ivy/
> > > http://www.xoocode.org/
> > >
> >
> >
> >
> >
> ____________________________________________________________________________________
> > Never miss a thing. Make Yahoo your home page.
> > http://www.yahoo.com/r/hs
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Stefan Bodewig <bo...@apache.org>.
"Xavier Hanin" <xa...@gmail.com> writes:
> On Jan 10, 2008 10:20 PM, Bruce Atherton <br...@callenish.com> wrote:
>
>> There used to be a project called Centipede that built Ant scripts
>> into something called "cents", which were attempts to capture best
>> practices for various parts of builds.
> It seems at least that it was done before ant 1.6, so before the
> import feature which is a key foundation of modular builds with Ant
> IMO.
One of Centipede's developers - Nikola Ken Barozzi - used to be
subscribed to this list. He contributed a lot to the Ant 1.6 feature
set, in particular import and PropertyHelpers IIRC.
> Hence I'm not sure if anything could be reused from this effort,
> except maybe some ideas, and feedback if we could get some members
> of the project on this discussion.
Like Bruce I think the project has died and it will be difficult to
get the old developers involved here.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Xavier Hanin <xa...@gmail.com>.
On Jan 10, 2008 10:20 PM, Bruce Atherton <br...@callenish.com> wrote:
> Gilles Scokart wrote:
> > Finally, I stopped my reflections, thinking that it is certainly
> something that already exists in the wild. Does it?
> If I remember correctly (it was a long time ago) it used to. There used
> to be a project called Centipede that built Ant scripts into something
> called "cents", which were attempts to capture best practices for
> various parts of builds. It eventually died, I think when Maven started
> taking off. It seemed to suffer from being part of a grander vision,
> called Krysalis, that dragged all resources away in different
> directions. That is my take as an outsider, anyway. I was never part of
> the project.
>
> You can still see the remnants of it on Sourceforge[1] and a home page[2].
Thanks for sharing this. I remember I had a look at this a long time ago,
probably before starting Ivy. From what we can see on the site, the goal was
very similar, but it's difficult to see how far it went. It seems at least
that it was done before ant 1.6, so before the import feature which is a key
foundation of modular builds with Ant IMO. Hence I'm not sure if anything
could be reused from this effort, except maybe some ideas, and feedback if
we could get some members of the project on this discussion.
Xavier
>
>
> [1] http://krysalis.sourceforge.net/centipede/
> [2] http://sourceforge.net/projects/krysalis/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects
Posted by Bruce Atherton <br...@callenish.com>.
Gilles Scokart wrote:
> Finally, I stopped my reflections, thinking that it is certainly something that already exists in the wild. Does it?
If I remember correctly (it was a long time ago) it used to. There used
to be a project called Centipede that built Ant scripts into something
called "cents", which were attempts to capture best practices for
various parts of builds. It eventually died, I think when Maven started
taking off. It seemed to suffer from being part of a grander vision,
called Krysalis, that dragged all resources away in different
directions. That is my take as an outsider, anyway. I was never part of
the project.
You can still see the remnants of it on Sourceforge[1] and a home page[2].
[1] http://krysalis.sourceforge.net/centipede/
[2] http://sourceforge.net/projects/krysalis/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Xavier Hanin <xa...@gmail.com>.
On Jan 10, 2008 6:18 PM, Wolfgang Häfelinger <wh...@epo.org> wrote:
> >> Is it open source or proprietary? Any link?
>
> Trying - unfortunatley for quite a while - to make it Open
> Source. So, sorry - no source code and no links at this
> moment.
>
> However, I'm quite willing to share some ideas, thoughts
> and I would not mind even to contribute ..
Great! It seems we are already gathering a little community in only a couple
of hours! It sounds like a very good sign :-)
Xavier
>
>
> Regards,
>
> Wolfgang Häfelinger
> Research & Architecture | Dir. 2.7.0.2
> European Patent Office
> Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
> Tel. +31 (0)70 340 4931
> whaefelinger@epo.org
> http://www.epo.org
>
>
>
>
> "Xavier Hanin" <xa...@gmail.com>
> 10-01-2008 18:04
> Please respond to
> "Ant Developers List" <de...@ant.apache.org>
>
>
> To
> "Ant Developers List" <de...@ant.apache.org>
> cc
>
> Subject
> Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
> projects
>
>
>
>
>
>
> On Jan 10, 2008 5:29 PM, Wolfgang Häfelinger <wh...@epo.org> wrote:
>
> > >> it is certainly something that already exists in the wild. Does it?
> >
> > It's called AntEpoline and lives currently in The Netherlands,
> > especially here at the EPO in The Hague.
>
> Is it open source or proprietary? Any link?
>
> Xavier
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects
Posted by Wolfgang Häfelinger <wh...@epo.org>.
>> Is it open source or proprietary? Any link?
Trying - unfortunatley for quite a while - to make it Open
Source. So, sorry - no source code and no links at this
moment.
However, I'm quite willing to share some ideas, thoughts
and I would not mind even to contribute ..
Regards,
Wolfgang Häfelinger
Research & Architecture | Dir. 2.7.0.2
European Patent Office
Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
Tel. +31 (0)70 340 4931
whaefelinger@epo.org
http://www.epo.org
"Xavier Hanin" <xa...@gmail.com>
10-01-2008 18:04
Please respond to
"Ant Developers List" <de...@ant.apache.org>
To
"Ant Developers List" <de...@ant.apache.org>
cc
Subject
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects
On Jan 10, 2008 5:29 PM, Wolfgang Häfelinger <wh...@epo.org> wrote:
> >> it is certainly something that already exists in the wild. Does it?
>
> It's called AntEpoline and lives currently in The Netherlands,
> especially here at the EPO in The Hague.
Is it open source or proprietary? Any link?
Xavier
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Xavier Hanin <xa...@gmail.com>.
On Jan 10, 2008 5:29 PM, Wolfgang Häfelinger <wh...@epo.org> wrote:
> >> it is certainly something that already exists in the wild. Does it?
>
> It's called AntEpoline and lives currently in The Netherlands,
> especially here at the EPO in The Hague.
Is it open source or proprietary? Any link?
Xavier
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Xavier Hanin <xa...@gmail.com>.
On Jan 11, 2008 5:14 PM, Dominique Devienne <dd...@gmail.com> wrote:
> On Jan 11, 2008 8:11 AM, Stefan Bodewig <bo...@apache.org> wrote:
> > "Gilles Scokart" <gs...@gmail.com> writes:
> >
> > > I never thought to overwrite macro to customize a generic build
> script. Can
> > > macro be overwritten?
> >
> > Sure, it's just another Ant task that has been defined.
>
> But my point is that most of the time, you never want to override
> things (macros or target), but augment them with some kind of pre or
> post processing. Peo's point of simply copy-pasting the "abstract"
> build code to fully override the target duplicates that code, and
> makes build maintenance all the more difficult. That's the well known
> issue with code generator and code wizards when it's done in a one-of
> way. Copy-pasting a target content shows failure of the generic build
> to be flexible, and should be the exception rather than the rule, and
> actually frowned upon IMHO. --DD
+1
Xavier
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Xavier Hanin <xa...@gmail.com>.
On Jan 11, 2008 5:40 PM, Peter Arrenbrecht <pe...@gmail.com>
wrote:
> [...]
> That is correct. However, being able to do it still beats not being
> able to. It allows for a better balancing of accommodating yet another
> esoteric hook request and making the template yet more complex vs.
> just telling someone to inline and tweak the template for their
> esoteric case.
>
> And being able to learn from looking at the imported script is also
> very valuable.
+1 too. This is a key foundation of the flexibility IMO. Trying to deliver a
build system which address everything is impossible, but it can always be a
good basis, at least to learn from. Leveraging the knowledge people have
from Ant syntax will help them to get value from the build system, even when
their problem is very specific.
Xavier
>
> But I think we understand each other, basically. ;)
>
> -peo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Peter Arrenbrecht <pe...@gmail.com>.
On Jan 11, 2008 5:14 PM, Dominique Devienne <dd...@gmail.com> wrote:
> On Jan 11, 2008 8:11 AM, Stefan Bodewig <bo...@apache.org> wrote:
> > "Gilles Scokart" <gs...@gmail.com> writes:
> >
> > > I never thought to overwrite macro to customize a generic build script. Can
> > > macro be overwritten?
> >
> > Sure, it's just another Ant task that has been defined.
>
> But my point is that most of the time, you never want to override
> things (macros or target), but augment them with some kind of pre or
> post processing. Peo's point of simply copy-pasting the "abstract"
> build code to fully override the target duplicates that code, and
> makes build maintenance all the more difficult. That's the well known
> issue with code generator and code wizards when it's done in a one-of
> way. Copy-pasting a target content shows failure of the generic build
> to be flexible, and should be the exception rather than the rule, and
> actually frowned upon IMHO. --DD
That is correct. However, being able to do it still beats not being
able to. It allows for a better balancing of accommodating yet another
esoteric hook request and making the template yet more complex vs.
just telling someone to inline and tweak the template for their
esoteric case.
And being able to learn from looking at the imported script is also
very valuable.
But I think we understand each other, basically. ;)
-peo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Xavier Hanin <xa...@gmail.com>.
On Jan 14, 2008 5:35 PM, Wolfgang Häfelinger <wh...@epo.org> wrote:
> > So every concrete simple target like <target name="foo" depends="bar,
> > baz" /> became
> >
> > <target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
> > <target name="-foo" > ... </target>
> > <target name="-pre-foo" />
> > <target name="-post-foo" />
>
> This looks pretty ugly this me!
If I understand correctly, that's exactly what Dominique complained about
:-)
>
>
> I believe that this whole discussion focusses too much on targets
> instead of macros. Macros are a very powerfull feature and they
> deserve much more attention!
>
> Why not simply:
>
> <!-- === framework === -->
> <target name="foo" depends="bar,baz" description="public foo target">
> <foo />
> </target>
>
> <macrodef name="foo" >
> <sequential>
> <!-- to the foo thing -->
> </sequential>
> </macrodef>
>
>
> If a user then really need to override "foo", he or she would simply
> write in build.xml something like
>
>
> <macrodef name="foo">
> <sequential>
> <echo> before original foo ..</echo>
>
> <c:foo /> <!-- assume framework in NS "c" />
>
> <echo> after original foo .. </echo>
> </sequential>
> </macrodef>
>
>
> Notice that I'm only using the name "foo" and not "-post-foo" and all
> your other names.
I'm not familiar with macro overriding, but how the custom foo macro get
called by the original foo target? Do you have to override the foo target to
call your custom foo macro?
Xavier
>
>
>
> Regards,
>
> Wolfgang Häfelinger
> Research & Architecture | Dir. 2.7.0.2
> European Patent Office
> Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
> Tel. +31 (0)70 340 4931
> whaefelinger@epo.org
> http://www.epo.org
>
>
>
>
> "Dominique Devienne" <dd...@gmail.com>
> 14-01-2008 17:17
> Please respond to
> "Ant Developers List" <de...@ant.apache.org>
>
>
> To
> "Ant Developers List" <de...@ant.apache.org>
> cc
>
> Subject
> Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
> projects
>
>
>
>
>
>
> On 1/14/08, Stefan Bodewig <bo...@apache.org> wrote:
> > "Dominique Devienne" <dd...@gmail.com> writes:
> > Having something like before/after/around advices (where around is the
> > same as an override that doesn't change the dependencies list) may
> > suffice and leave overwriting the whole target definition to the worst
> > case.
>
> Thanks for reminding me of this issue Stefan. Indeed, something I
> really didn't like about overriding the whole target, is that you had
> to duplicate the dependency list as well...
>
> Which is why I now remember that I now remember I used 4, not 3
> targets, in the "abstract" build, the forth one being the target's own
> content, separate from its dependency list:
>
> So every concrete simple target like <target name="foo" depends="bar,
> baz" /> became
>
> <target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
> <target name="-foo" > ... </target>
> <target name="-pre-foo" />
> <target name="-post-foo" />
>
> in the "abstract" build. Override -foo to replace just the target
> content, without it's dependency list. Or override foo to have
> complete control, but in my experience it's -foo that needed
> overriding, not foo.
>
> Note though that unlike before and after, around isn't as
> representative a name. When I thought about this issue a while back, I
> thought of using a magic name such as "super" in the depends attribute
> to refer to the overridden target's dependency list, similar to using
> <super/> in the target's body to refer to the overridden target's task
> list/content. --DD
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Xavier Hanin <xa...@gmail.com>.
On Jan 15, 2008 6:31 AM, Stefan Bodewig <bo...@apache.org> wrote:
> "Peter Reilly" <pe...@gmail.com> writes:
>
> > I would say that if the build file does not specify the order, then the
> order
> > is undefined.
> >
> > If the order is important, then the build file can enforce an order by
> > using "depends".
> >
> > <target name="prepare" before="junit" depends="start-server">
> > <prepare />
> > </target>
>
> One thing we are not taking into account is the plugin approach that
> is part of Xavier's initial EasyAnt vision.
>
> If our base build file contains a compile target and several "plugins"
> that I want to use need to do stuff before the compile target then we
> need a way to have a defined order. In the order my build file
> requires the plugins, I guess.
Yes, I agree order should be predictable, and keeping definition order seems
fine.
>
>
> Do we revert the order for after targets so the first one declared
> gets executed last?
Why not. But in my mind if you really need to do something surrounding a
target, you'd better use the around mechanism than the after / before. I
think it's more explicit.
The problem with the around mechanism as I see it (which is basically an
override with a mean to call the original definition) is the interaction
between plugins. If several plugins use the around mechanism, it maybe
difficult to understand that the call to the original defintion actually
call the definition overriden by another plugin. And if one plugin actually
overrides a definition without calling the original definition, then the
order will be very important: if it's defined after a plugin overriding just
for the around, then I guess the final override will override everything
including the overriden definition. So it's very different from what would
have happened while using a before and after targets (well, as I see it, see
below).
>
>
> Also we will need to define how before/after an complete overriding of
> targets interact. Do before/after apply to the new definition of the
> target or are they dropped?
I'd say they apply to the new definition. If we take the example of the
server start / stop, I think it still makes sense to run 'em when another
plugin redefines how the unit tests are run. In my mind plugins interactions
should be kept minimal as long as they aren't explicitly desired. If a
plugin really wants to disable another plugin 'before' target, then we
should provide a mean to do it, like overriding the before target. I'm not
sure if there is a use case for that though. As I said before the main
problem about plugin interaction is when two plugins override the definition
of a target, and at least one doesn't call the original definition. Maybe
this shouldn't be considered at the same level: defining before and after
targets can be seen as a plugin contribution. Overriding a target is closer
to OO inheritance, and as such maybe could be allowed only when a build
script 'extends' another one.
Hence we would have two kind of relationship between build modules:
- a build module 'contributes' to another one, in which case it can only
define after/before targets. This is called a plugin.
- a build module 'extends' another one, in which case it can override parent
target(s) definition(s)
Only one 'extension' of a given module can be used at a time in the build
system, while the number of contributions is not limited.
Does this make sense?
Xavier
>
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
RE: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Gilles Scokart <gs...@gmail.com>.
By the way, a truly generic build script will probably have to support 2 level of customization/extension.
The first one being an enterprise level, and the second one being at project level.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Dominique Devienne <dd...@gmail.com>.
On 1/14/08, Stefan Bodewig <bo...@apache.org> wrote:
> If our base build file contains a compile target and several "plugins"
> that I want to use need to do stuff before the compile target then we
> need a way to have a defined order. In the order my build file
> requires the plugins, I guess.
So far we've been talking mostly about a concrete build needing a
customize the behavior of a base generic build, typically with some
pre or post processing, and sometimes complete override of the target
(w/ or w/o changing the dependency list), but when you mentioned the
plugins scenario, it made me think of a "composite" build made up of
several builds you'd import, all with a compile target, where you'd
want the compile targets to somehow "aggregate" into a single compile
target... So instead of doing a <subant> on these builds, you'd import
them, and they "merge" into one build. Sounds a bit crazy, I agree. Oh
well, I'm throwing it out there, but it's probably too weird.
I'd be quite happy if we simply added before/after support, nailing
down the exact desired behavior. Maybe we should indeed do that in
another thread. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Stefan Bodewig <bo...@apache.org>.
"Peter Reilly" <pe...@gmail.com> writes:
> I would say that if the build file does not specify the order, then the order
> is undefined.
>
> If the order is important, then the build file can enforce an order by
> using "depends".
>
> <target name="prepare" before="junit" depends="start-server">
> <prepare />
> </target>
One thing we are not taking into account is the plugin approach that
is part of Xavier's initial EasyAnt vision.
If our base build file contains a compile target and several "plugins"
that I want to use need to do stuff before the compile target then we
need a way to have a defined order. In the order my build file
requires the plugins, I guess.
Do we revert the order for after targets so the first one declared
gets executed last?
Also we will need to define how before/after an complete overriding of
targets interact. Do before/after apply to the new definition of the
target or are they dropped?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Peter Reilly <pe...@gmail.com>.
On Jan 14, 2008 5:24 PM, Peter Reilly <pe...@gmail.com> wrote:
> On Jan 14, 2008 5:02 PM, Wolfgang Häfelinger <wh...@epo.org> wrote:
> > Assume also:
> >
> > <target name="prepare" before="junit">
> > <prepare />
> > </target>
> >
> > Do you want this before your "start-server" or after it or
> > in parallel?
> >
>
> I would say that if the build file does not specify the order, then the order
> is undefined.
>
This would be similar to the @Before and @After annotations in junit.
Peter
> If the order is important, then the build file can enforce an order by
> using "depends".
>
> <target name="prepare" before="junit" depends="start-server">
> <prepare />
> </target>
>
> Peter
>
> > And you you need to extend Ant with "before" and "after" of
> > course.
> >
> >
> > Regards,
> >
> > Wolfgang Häfelinger
> > Research & Architecture | Dir. 2.7.0.2
> > European Patent Office
> > Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
> > Tel. +31 (0)70 340 4931
> > whaefelinger@epo.org
> > http://www.epo.org
> >
> >
> >
> >
> > "Peter Reilly" <pe...@gmail.com>
> > 14-01-2008 17:52
> >
> > Please respond to
> > "Ant Developers List" <de...@ant.apache.org>
> >
> >
> > To
> > "Ant Developers List" <de...@ant.apache.org>
> > cc
> >
> > Subject
> > Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
> > projects
> >
> >
> >
> >
> >
> >
> > Why not have something simple like having a "before" and "after"
> > attributes to
> > the <target> element.
> >
> > <project ...>
> > ...
> > <import file="${commons.dir}/ant-setup.xml"/> <!-- defines common
> > build, junit, javadoc etc -->
> >
> > <target name="start-server" before="junit">
> > <start-server/>
> > </target>
> >
> >
> > <target name="stop-server" after="junit">
> > <stop-the-server/>
> > </target>
> >
> >
> > </target>
> >
> > Peter
> >
> > On Jan 14, 2008 4:35 PM, Wolfgang Häfelinger <wh...@epo.org> wrote:
> > > > So every concrete simple target like <target name="foo" depends="bar,
> > > > baz" /> became
> > > >
> > > > <target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
> > > > <target name="-foo" > ... </target>
> > > > <target name="-pre-foo" />
> > > > <target name="-post-foo" />
> > >
> > > This looks pretty ugly this me!
> > >
> > > I believe that this whole discussion focusses too much on targets
> > > instead of macros. Macros are a very powerfull feature and they
> > > deserve much more attention!
> > >
> > > Why not simply:
> > >
> > > <!-- === framework === -->
> > > <target name="foo" depends="bar,baz" description="public foo target">
> > > <foo />
> > > </target>
> > >
> > > <macrodef name="foo" >
> > > <sequential>
> > > <!-- to the foo thing -->
> > > </sequential>
> > > </macrodef>
> > >
> > >
> > > If a user then really need to override "foo", he or she would simply
> > > write in build.xml something like
> > >
> > >
> > > <macrodef name="foo">
> > > <sequential>
> > > <echo> before original foo ..</echo>
> > >
> > > <c:foo /> <!-- assume framework in NS "c" />
> > >
> > > <echo> after original foo .. </echo>
> > > </sequential>
> > > </macrodef>
> > >
> > >
> > > Notice that I'm only using the name "foo" and not "-post-foo" and all
> > > your other names.
> > >
> > >
> > > Regards,
> > >
> > > Wolfgang Häfelinger
> > > Research & Architecture | Dir. 2.7.0.2
> > > European Patent Office
> > > Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
> > > Tel. +31 (0)70 340 4931
> > > whaefelinger@epo.org
> > > http://www.epo.org
> > >
> > >
> > >
> > >
> > > "Dominique Devienne" <dd...@gmail.com>
> > > 14-01-2008 17:17
> > > Please respond to
> > > "Ant Developers List" <de...@ant.apache.org>
> > >
> > >
> > > To
> > > "Ant Developers List" <de...@ant.apache.org>
> > > cc
> > >
> > > Subject
> > > Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
> > > projects
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On 1/14/08, Stefan Bodewig <bo...@apache.org> wrote:
> > > > "Dominique Devienne" <dd...@gmail.com> writes:
> > > > Having something like before/after/around advices (where around is the
> > > > same as an override that doesn't change the dependencies list) may
> > > > suffice and leave overwriting the whole target definition to the worst
> > > > case.
> > >
> > > Thanks for reminding me of this issue Stefan. Indeed, something I
> > > really didn't like about overriding the whole target, is that you had
> > > to duplicate the dependency list as well...
> > >
> > > Which is why I now remember that I now remember I used 4, not 3
> > > targets, in the "abstract" build, the forth one being the target's own
> > > content, separate from its dependency list:
> > >
> > > So every concrete simple target like <target name="foo" depends="bar,
> > > baz" /> became
> > >
> > > <target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
> > > <target name="-foo" > ... </target>
> > > <target name="-pre-foo" />
> > > <target name="-post-foo" />
> > >
> > > in the "abstract" build. Override -foo to replace just the target
> > > content, without it's dependency list. Or override foo to have
> > > complete control, but in my experience it's -foo that needed
> > > overriding, not foo.
> > >
> > > Note though that unlike before and after, around isn't as
> > > representative a name. When I thought about this issue a while back, I
> > > thought of using a magic name such as "super" in the depends attribute
> > > to refer to the overridden target's dependency list, similar to using
> > > <super/> in the target's body to refer to the overridden target's task
> > > list/content. --DD
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > > For additional commands, e-mail: dev-help@ant.apache.org
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Dominique Devienne <dd...@gmail.com>.
On 1/14/08, Wolfgang Häfelinger <wh...@epo.org> wrote:
> > Q1: Does everyone agree that adding before/after to target to Ant 1.8
> > is useful and should be done before (in conjunction of) creating
> > generic build files?
>
> could you please explain why you see a need for target attributes "before"
> and "after" rather than following the Macro path I proposed?
I guess because I think in terms of targets and not macros. I've used
macros, but to define new "tasks", not to control the structure of the
build itself. For that, targets and dependencies are the building
blocks IMHO.
At this point I don't understand the macro approach that you advocate,
and even if it worked, I'd argue that it may not be the "natural" way
to add the flexibility we have been discussing about. Could very well
be that I'm wrong, but at this point it's my thinking.
The fact that your macro approach to extensibility works without
changes to Ant is nice but not a strong-enough point to me, if it
feels less natural that the before/after target approach that would
require changes in Ant. I.e. I care more about the user friendliness
and doing it in a simple and natural way, than the implementation
details. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects
Posted by Wolfgang Häfelinger <wh...@epo.org>.
> Q1: Does everyone agree that adding before/after to target to Ant 1.8
> is useful and should be done before (in conjunction of) creating
> generic build files?
Dominique and Peter,
could you please explain why you see a need for target attributes "before"
and "after" rather
than following the Macro path I proposed?
Regards,
Wolfgang Häfelinger
Research & Architecture | Dir. 2.7.0.2
European Patent Office
Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
Tel. +31 (0)70 340 4931
whaefelinger@epo.org
http://www.epo.org
"Dominique Devienne" <dd...@gmail.com>
14-01-2008 18:39
Please respond to
"Ant Developers List" <de...@ant.apache.org>
To
"Ant Developers List" <de...@ant.apache.org>
cc
Subject
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects
On 1/14/08, Peter Reilly <pe...@gmail.com> wrote:
> On Jan 14, 2008 5:02 PM, Wolfgang Häfelinger <wh...@epo.org>
wrote:
> > Assume also:
> >
> > <target name="prepare" before="junit">
> > <prepare />
> > </target>
> >
> > Do you want this before your "start-server" or after it or
> > in parallel?
> >
>
> I would say that if the build file does not specify the order, then the
order
> is undefined.
>
> If the order is important, then the build file can enforce an order by
> using "depends".
>
> <target name="prepare" before="junit" depends="start-server">
> <prepare />
> </target>
It makes sense Peter. And this already works in Ant, provided we add
before/after support to <target>.
Q1: Does everyone agree that adding before/after to target to Ant 1.8
is useful and should be done before (in conjunction of) creating
generic build files?
Q2: Do others feel (like me) that we should also have a mean to
override a target's content (task list) while keeping the overridden
target's dependency list?
Both questions above are independent of using overriding macros... --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Peter Reilly <pe...@gmail.com>.
On Jan 14, 2008 5:39 PM, Dominique Devienne <dd...@gmail.com> wrote:
> On 1/14/08, Peter Reilly <pe...@gmail.com> wrote:
> > On Jan 14, 2008 5:02 PM, Wolfgang Häfelinger <wh...@epo.org> wrote:
> > > Assume also:
> > >
> > > <target name="prepare" before="junit">
> > > <prepare />
> > > </target>
> > >
> > > Do you want this before your "start-server" or after it or
> > > in parallel?
> > >
> >
> > I would say that if the build file does not specify the order, then the order
> > is undefined.
> >
> > If the order is important, then the build file can enforce an order by
> > using "depends".
> >
> > <target name="prepare" before="junit" depends="start-server">
> > <prepare />
> > </target>
>
> It makes sense Peter. And this already works in Ant, provided we add
> before/after support to <target>.
Opps, I just read the previous e-mails, and yes you have proposed this
syntax!.
>
> Q1: Does everyone agree that adding before/after to target to Ant 1.8
> is useful and should be done before (in conjunction of) creating
> generic build files?
>
> Q2: Do others feel (like me) that we should also have a mean to
> override a target's content (task list) while keeping the overridden
> target's dependency list?
This is the <target override="build"> syntax?
I am a little dubious, but could be swayed.
Peter
>
> Both questions above are independent of using overriding macros... --DD
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Guntis Ozols <gu...@latnet.lv>.
> > > > Assume also:
> > > >
> > > > <target name="prepare" before="junit">
> > > > <prepare />
> > > > </target>
> > > >
> > > > Do you want this before your "start-server" or after it or
> > > > in parallel?
> > > >
> > >
> > > I would say that if the build file does not specify the order,
> > > then the order is undefined.
maybe document order and import tree can be used to define that order?
> > > If the order is important, then the build file can enforce an order by
> > > using "depends".
> > >
> > > <target name="prepare" before="junit" depends="start-server">
> > > <prepare />
> > > </target>
> >
> > It makes sense Peter. And this already works in Ant, provided we add
> > before/after support to <target>.
> >
> > Q1: Does everyone agree that adding before/after to target to Ant 1.8
> > is useful and should be done before (in conjunction of) creating
> > generic build files?
>
> I agree, this seems easily understandable (even though when used in
> conjunction with depends it may seem a bit complex, but this shouldn't
> be needed very often) and use the usual Ant building blocks.
>
> >
> >
> > Q2: Do others feel (like me) that we should also have a mean to
> > override a target's content (task list) while keeping the overridden
> > target's dependency list?
>
> I do. And also add the <super /> element you were talking about.
>
> Xavier
a) override="both"
b) override="content"
c) warn otherwise!
Guntis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Peter Arrenbrecht <pe...@gmail.com>.
On Jan 14, 2008 9:37 PM, Xavier Hanin <xa...@gmail.com> wrote:
> On Jan 14, 2008 6:39 PM, Dominique Devienne <dd...@gmail.com> wrote:
> > Q1: Does everyone agree that adding before/after to target to Ant 1.8
> > is useful and should be done before (in conjunction of) creating
> > generic build files?
>
> I agree, this seems easily understandable (even though when used in
> conjunction with depends it may seem a bit complex, but this shouldn't be
> needed very often) and use the usual Ant building blocks.
I agree. Feels much more natural than macros.
> > Q2: Do others feel (like me) that we should also have a mean to
> > override a target's content (task list) while keeping the overridden
> > target's dependency list?
>
> I do. And also add the <super /> element you were talking about.
I agree. For what it's worth, I think we should also have a means to
externally trigger just the body of a task (mainly during build script
debugging). I normally do
tgt depend " -tgt"
-tgt depend "@tgt-step1, @tgt-step2, ..."
Meaning I can call the building blocks @tgt-stepN from outside to
incrementally watch and refine their behaviour.
-peo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Xavier Hanin <xa...@gmail.com>.
On Jan 14, 2008 6:39 PM, Dominique Devienne <dd...@gmail.com> wrote:
> On 1/14/08, Peter Reilly <pe...@gmail.com> wrote:
> > On Jan 14, 2008 5:02 PM, Wolfgang Häfelinger <wh...@epo.org>
> wrote:
> > > Assume also:
> > >
> > > <target name="prepare" before="junit">
> > > <prepare />
> > > </target>
> > >
> > > Do you want this before your "start-server" or after it or
> > > in parallel?
> > >
> >
> > I would say that if the build file does not specify the order, then the
> order
> > is undefined.
> >
> > If the order is important, then the build file can enforce an order by
> > using "depends".
> >
> > <target name="prepare" before="junit" depends="start-server">
> > <prepare />
> > </target>
>
> It makes sense Peter. And this already works in Ant, provided we add
> before/after support to <target>.
>
> Q1: Does everyone agree that adding before/after to target to Ant 1.8
> is useful and should be done before (in conjunction of) creating
> generic build files?
I agree, this seems easily understandable (even though when used in
conjunction with depends it may seem a bit complex, but this shouldn't be
needed very often) and use the usual Ant building blocks.
>
>
> Q2: Do others feel (like me) that we should also have a mean to
> override a target's content (task list) while keeping the overridden
> target's dependency list?
I do. And also add the <super /> element you were talking about.
Xavier
>
>
> Both questions above are independent of using overriding macros... --DD
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects
Posted by Wolfgang Häfelinger <wh...@epo.org>.
> Q1: Does everyone agree that adding before/after to target to Ant 1.8
> is useful and should be done before (in conjunction of) creating
> generic build files?
Ok, I'm not a committer - anyhow:
I disagree cause you can do the very same thing just with Macros.
No need for new target attributes.
> Q2: Do others feel (like me) that we should also have a mean to
> override a target's content (task list) while keeping the overridden
> target's dependency list?
This must be the soul of this whole upcoming framework. It's an
absolutley must.
Regards,
Wolfgang Häfelinger
Research & Architecture | Dir. 2.7.0.2
European Patent Office
Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
Tel. +31 (0)70 340 4931
whaefelinger@epo.org
http://www.epo.org
"Dominique Devienne" <dd...@gmail.com>
14-01-2008 18:39
Please respond to
"Ant Developers List" <de...@ant.apache.org>
To
"Ant Developers List" <de...@ant.apache.org>
cc
Subject
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects
On 1/14/08, Peter Reilly <pe...@gmail.com> wrote:
> On Jan 14, 2008 5:02 PM, Wolfgang Häfelinger <wh...@epo.org>
wrote:
> > Assume also:
> >
> > <target name="prepare" before="junit">
> > <prepare />
> > </target>
> >
> > Do you want this before your "start-server" or after it or
> > in parallel?
> >
>
> I would say that if the build file does not specify the order, then the
order
> is undefined.
>
> If the order is important, then the build file can enforce an order by
> using "depends".
>
> <target name="prepare" before="junit" depends="start-server">
> <prepare />
> </target>
It makes sense Peter. And this already works in Ant, provided we add
before/after support to <target>.
Q1: Does everyone agree that adding before/after to target to Ant 1.8
is useful and should be done before (in conjunction of) creating
generic build files?
Q2: Do others feel (like me) that we should also have a mean to
override a target's content (task list) while keeping the overridden
target's dependency list?
Both questions above are independent of using overriding macros... --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Dominique Devienne <dd...@gmail.com>.
On 1/14/08, Peter Reilly <pe...@gmail.com> wrote:
> On Jan 14, 2008 5:02 PM, Wolfgang Häfelinger <wh...@epo.org> wrote:
> > Assume also:
> >
> > <target name="prepare" before="junit">
> > <prepare />
> > </target>
> >
> > Do you want this before your "start-server" or after it or
> > in parallel?
> >
>
> I would say that if the build file does not specify the order, then the order
> is undefined.
>
> If the order is important, then the build file can enforce an order by
> using "depends".
>
> <target name="prepare" before="junit" depends="start-server">
> <prepare />
> </target>
It makes sense Peter. And this already works in Ant, provided we add
before/after support to <target>.
Q1: Does everyone agree that adding before/after to target to Ant 1.8
is useful and should be done before (in conjunction of) creating
generic build files?
Q2: Do others feel (like me) that we should also have a mean to
override a target's content (task list) while keeping the overridden
target's dependency list?
Both questions above are independent of using overriding macros... --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Peter Reilly <pe...@gmail.com>.
On Jan 14, 2008 5:02 PM, Wolfgang Häfelinger <wh...@epo.org> wrote:
> Assume also:
>
> <target name="prepare" before="junit">
> <prepare />
> </target>
>
> Do you want this before your "start-server" or after it or
> in parallel?
>
I would say that if the build file does not specify the order, then the order
is undefined.
If the order is important, then the build file can enforce an order by
using "depends".
<target name="prepare" before="junit" depends="start-server">
<prepare />
</target>
Peter
> And you you need to extend Ant with "before" and "after" of
> course.
>
>
> Regards,
>
> Wolfgang Häfelinger
> Research & Architecture | Dir. 2.7.0.2
> European Patent Office
> Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
> Tel. +31 (0)70 340 4931
> whaefelinger@epo.org
> http://www.epo.org
>
>
>
>
> "Peter Reilly" <pe...@gmail.com>
> 14-01-2008 17:52
>
> Please respond to
> "Ant Developers List" <de...@ant.apache.org>
>
>
> To
> "Ant Developers List" <de...@ant.apache.org>
> cc
>
> Subject
> Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
> projects
>
>
>
>
>
>
> Why not have something simple like having a "before" and "after"
> attributes to
> the <target> element.
>
> <project ...>
> ...
> <import file="${commons.dir}/ant-setup.xml"/> <!-- defines common
> build, junit, javadoc etc -->
>
> <target name="start-server" before="junit">
> <start-server/>
> </target>
>
>
> <target name="stop-server" after="junit">
> <stop-the-server/>
> </target>
>
>
> </target>
>
> Peter
>
> On Jan 14, 2008 4:35 PM, Wolfgang Häfelinger <wh...@epo.org> wrote:
> > > So every concrete simple target like <target name="foo" depends="bar,
> > > baz" /> became
> > >
> > > <target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
> > > <target name="-foo" > ... </target>
> > > <target name="-pre-foo" />
> > > <target name="-post-foo" />
> >
> > This looks pretty ugly this me!
> >
> > I believe that this whole discussion focusses too much on targets
> > instead of macros. Macros are a very powerfull feature and they
> > deserve much more attention!
> >
> > Why not simply:
> >
> > <!-- === framework === -->
> > <target name="foo" depends="bar,baz" description="public foo target">
> > <foo />
> > </target>
> >
> > <macrodef name="foo" >
> > <sequential>
> > <!-- to the foo thing -->
> > </sequential>
> > </macrodef>
> >
> >
> > If a user then really need to override "foo", he or she would simply
> > write in build.xml something like
> >
> >
> > <macrodef name="foo">
> > <sequential>
> > <echo> before original foo ..</echo>
> >
> > <c:foo /> <!-- assume framework in NS "c" />
> >
> > <echo> after original foo .. </echo>
> > </sequential>
> > </macrodef>
> >
> >
> > Notice that I'm only using the name "foo" and not "-post-foo" and all
> > your other names.
> >
> >
> > Regards,
> >
> > Wolfgang Häfelinger
> > Research & Architecture | Dir. 2.7.0.2
> > European Patent Office
> > Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
> > Tel. +31 (0)70 340 4931
> > whaefelinger@epo.org
> > http://www.epo.org
> >
> >
> >
> >
> > "Dominique Devienne" <dd...@gmail.com>
> > 14-01-2008 17:17
> > Please respond to
> > "Ant Developers List" <de...@ant.apache.org>
> >
> >
> > To
> > "Ant Developers List" <de...@ant.apache.org>
> > cc
> >
> > Subject
> > Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
> > projects
> >
> >
> >
> >
> >
> >
> >
> > On 1/14/08, Stefan Bodewig <bo...@apache.org> wrote:
> > > "Dominique Devienne" <dd...@gmail.com> writes:
> > > Having something like before/after/around advices (where around is the
> > > same as an override that doesn't change the dependencies list) may
> > > suffice and leave overwriting the whole target definition to the worst
> > > case.
> >
> > Thanks for reminding me of this issue Stefan. Indeed, something I
> > really didn't like about overriding the whole target, is that you had
> > to duplicate the dependency list as well...
> >
> > Which is why I now remember that I now remember I used 4, not 3
> > targets, in the "abstract" build, the forth one being the target's own
> > content, separate from its dependency list:
> >
> > So every concrete simple target like <target name="foo" depends="bar,
> > baz" /> became
> >
> > <target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
> > <target name="-foo" > ... </target>
> > <target name="-pre-foo" />
> > <target name="-post-foo" />
> >
> > in the "abstract" build. Override -foo to replace just the target
> > content, without it's dependency list. Or override foo to have
> > complete control, but in my experience it's -foo that needed
> > overriding, not foo.
> >
> > Note though that unlike before and after, around isn't as
> > representative a name. When I thought about this issue a while back, I
> > thought of using a magic name such as "super" in the depends attribute
> > to refer to the overridden target's dependency list, similar to using
> > <super/> in the target's body to refer to the overridden target's task
> > list/content. --DD
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Dominique Devienne <dd...@gmail.com>.
On 1/14/08, Peter Reilly <pe...@gmail.com> wrote:
> Why not have something simple like having a "before" and "after" attributes to
> the <target> element.
This is indeed something we discussed and proposed earlier in the
thread. (except I envisioned the before/after to be used instead of
the name attribute, although giving a more explicit name to the target
is a good optional think I now realize, and is independent of the
target being "injected" into the dependency chain at the correct
place).
But is it that simple? If you have several such before/after targets,
what order are they executed in? What is they are spread into several
files? And if you give them names, do these before/after targets
themselves become override-able?
Even this simple (very desirable!) feature can get hairy when one digs
a little before the surface. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects
Posted by Wolfgang Häfelinger <wh...@epo.org>.
Assume also:
<target name="prepare" before="junit">
<prepare />
</target>
Do you want this before your "start-server" or after it or
in parallel?
And you you need to extend Ant with "before" and "after" of
course.
Regards,
Wolfgang Häfelinger
Research & Architecture | Dir. 2.7.0.2
European Patent Office
Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
Tel. +31 (0)70 340 4931
whaefelinger@epo.org
http://www.epo.org
"Peter Reilly" <pe...@gmail.com>
14-01-2008 17:52
Please respond to
"Ant Developers List" <de...@ant.apache.org>
To
"Ant Developers List" <de...@ant.apache.org>
cc
Subject
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects
Why not have something simple like having a "before" and "after"
attributes to
the <target> element.
<project ...>
...
<import file="${commons.dir}/ant-setup.xml"/> <!-- defines common
build, junit, javadoc etc -->
<target name="start-server" before="junit">
<start-server/>
</target>
<target name="stop-server" after="junit">
<stop-the-server/>
</target>
</target>
Peter
On Jan 14, 2008 4:35 PM, Wolfgang Häfelinger <wh...@epo.org> wrote:
> > So every concrete simple target like <target name="foo" depends="bar,
> > baz" /> became
> >
> > <target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
> > <target name="-foo" > ... </target>
> > <target name="-pre-foo" />
> > <target name="-post-foo" />
>
> This looks pretty ugly this me!
>
> I believe that this whole discussion focusses too much on targets
> instead of macros. Macros are a very powerfull feature and they
> deserve much more attention!
>
> Why not simply:
>
> <!-- === framework === -->
> <target name="foo" depends="bar,baz" description="public foo target">
> <foo />
> </target>
>
> <macrodef name="foo" >
> <sequential>
> <!-- to the foo thing -->
> </sequential>
> </macrodef>
>
>
> If a user then really need to override "foo", he or she would simply
> write in build.xml something like
>
>
> <macrodef name="foo">
> <sequential>
> <echo> before original foo ..</echo>
>
> <c:foo /> <!-- assume framework in NS "c" />
>
> <echo> after original foo .. </echo>
> </sequential>
> </macrodef>
>
>
> Notice that I'm only using the name "foo" and not "-post-foo" and all
> your other names.
>
>
> Regards,
>
> Wolfgang Häfelinger
> Research & Architecture | Dir. 2.7.0.2
> European Patent Office
> Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
> Tel. +31 (0)70 340 4931
> whaefelinger@epo.org
> http://www.epo.org
>
>
>
>
> "Dominique Devienne" <dd...@gmail.com>
> 14-01-2008 17:17
> Please respond to
> "Ant Developers List" <de...@ant.apache.org>
>
>
> To
> "Ant Developers List" <de...@ant.apache.org>
> cc
>
> Subject
> Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
> projects
>
>
>
>
>
>
>
> On 1/14/08, Stefan Bodewig <bo...@apache.org> wrote:
> > "Dominique Devienne" <dd...@gmail.com> writes:
> > Having something like before/after/around advices (where around is the
> > same as an override that doesn't change the dependencies list) may
> > suffice and leave overwriting the whole target definition to the worst
> > case.
>
> Thanks for reminding me of this issue Stefan. Indeed, something I
> really didn't like about overriding the whole target, is that you had
> to duplicate the dependency list as well...
>
> Which is why I now remember that I now remember I used 4, not 3
> targets, in the "abstract" build, the forth one being the target's own
> content, separate from its dependency list:
>
> So every concrete simple target like <target name="foo" depends="bar,
> baz" /> became
>
> <target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
> <target name="-foo" > ... </target>
> <target name="-pre-foo" />
> <target name="-post-foo" />
>
> in the "abstract" build. Override -foo to replace just the target
> content, without it's dependency list. Or override foo to have
> complete control, but in my experience it's -foo that needed
> overriding, not foo.
>
> Note though that unlike before and after, around isn't as
> representative a name. When I thought about this issue a while back, I
> thought of using a magic name such as "super" in the depends attribute
> to refer to the overridden target's dependency list, similar to using
> <super/> in the target's body to refer to the overridden target's task
> list/content. --DD
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Peter Reilly <pe...@gmail.com>.
Why not have something simple like having a "before" and "after" attributes to
the <target> element.
<project ...>
...
<import file="${commons.dir}/ant-setup.xml"/> <!-- defines common
build, junit, javadoc etc -->
<target name="start-server" before="junit">
<start-server/>
</target>
<target name="stop-server" after="junit">
<stop-the-server/>
</target>
</target>
Peter
On Jan 14, 2008 4:35 PM, Wolfgang Häfelinger <wh...@epo.org> wrote:
> > So every concrete simple target like <target name="foo" depends="bar,
> > baz" /> became
> >
> > <target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
> > <target name="-foo" > ... </target>
> > <target name="-pre-foo" />
> > <target name="-post-foo" />
>
> This looks pretty ugly this me!
>
> I believe that this whole discussion focusses too much on targets
> instead of macros. Macros are a very powerfull feature and they
> deserve much more attention!
>
> Why not simply:
>
> <!-- === framework === -->
> <target name="foo" depends="bar,baz" description="public foo target">
> <foo />
> </target>
>
> <macrodef name="foo" >
> <sequential>
> <!-- to the foo thing -->
> </sequential>
> </macrodef>
>
>
> If a user then really need to override "foo", he or she would simply
> write in build.xml something like
>
>
> <macrodef name="foo">
> <sequential>
> <echo> before original foo ..</echo>
>
> <c:foo /> <!-- assume framework in NS "c" />
>
> <echo> after original foo .. </echo>
> </sequential>
> </macrodef>
>
>
> Notice that I'm only using the name "foo" and not "-post-foo" and all
> your other names.
>
>
> Regards,
>
> Wolfgang Häfelinger
> Research & Architecture | Dir. 2.7.0.2
> European Patent Office
> Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
> Tel. +31 (0)70 340 4931
> whaefelinger@epo.org
> http://www.epo.org
>
>
>
>
> "Dominique Devienne" <dd...@gmail.com>
> 14-01-2008 17:17
> Please respond to
> "Ant Developers List" <de...@ant.apache.org>
>
>
> To
> "Ant Developers List" <de...@ant.apache.org>
> cc
>
> Subject
> Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
> projects
>
>
>
>
>
>
>
> On 1/14/08, Stefan Bodewig <bo...@apache.org> wrote:
> > "Dominique Devienne" <dd...@gmail.com> writes:
> > Having something like before/after/around advices (where around is the
> > same as an override that doesn't change the dependencies list) may
> > suffice and leave overwriting the whole target definition to the worst
> > case.
>
> Thanks for reminding me of this issue Stefan. Indeed, something I
> really didn't like about overriding the whole target, is that you had
> to duplicate the dependency list as well...
>
> Which is why I now remember that I now remember I used 4, not 3
> targets, in the "abstract" build, the forth one being the target's own
> content, separate from its dependency list:
>
> So every concrete simple target like <target name="foo" depends="bar,
> baz" /> became
>
> <target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
> <target name="-foo" > ... </target>
> <target name="-pre-foo" />
> <target name="-post-foo" />
>
> in the "abstract" build. Override -foo to replace just the target
> content, without it's dependency list. Or override foo to have
> complete control, but in my experience it's -foo that needed
> overriding, not foo.
>
> Note though that unlike before and after, around isn't as
> representative a name. When I thought about this issue a while back, I
> thought of using a magic name such as "super" in the depends attribute
> to refer to the overridden target's dependency list, similar to using
> <super/> in the target's body to refer to the overridden target's task
> list/content. --DD
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Gilles Scokart <gs...@gmail.com>.
2008/1/14, Dominique Devienne <dd...@gmail.com>:
>
> On 1/14/08, Stefan Bodewig <bo...@apache.org> wrote:
> > "Dominique Devienne" <dd...@gmail.com> writes:
> > Having something like before/after/around advices (where around is the
> > same as an override that doesn't change the dependencies list) may
> > suffice and leave overwriting the whole target definition to the worst
> > case.
>
> Thanks for reminding me of this issue Stefan. Indeed, something I
> really didn't like about overriding the whole target, is that you had
> to duplicate the dependency list as well...
>
> Which is why I now remember that I now remember I used 4, not 3
> targets, in the "abstract" build, the forth one being the target's own
> content, separate from its dependency list:
>
> So every concrete simple target like <target name="foo" depends="bar,
> baz" /> became
>
> <target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
> <target name="-foo" > ... </target>
> <target name="-pre-foo" />
> <target name="-post-foo" />
>
> in the "abstract" build. Override -foo to replace just the target
> content, without it's dependency list. Or override foo to have
> complete control, but in my experience it's -foo that needed
> overriding, not foo.
>
> Note though that unlike before and after, around isn't as
> representative a name. When I thought about this issue a while back, I
> thought of using a magic name such as "super" in the depends attribute
> to refer to the overridden target's dependency list, similar to using
> <super/> in the target's body to refer to the overridden target's task
> list/content. --DD
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Using the imported_script_name.target syntax give you already some
flexibility.
--
Gilles Scokart
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Stefan Bodewig <bo...@apache.org>.
Wolfgang Häfelinger <wh...@epo.org> writes:
> Why not simply:
>
> <!-- === framework === -->
> <target name="foo" depends="bar,baz" description="public foo target">
> <foo />
> </target>
>
> <macrodef name="foo" >
> <sequential>
> <!-- to the foo thing -->
> </sequential>
> </macrodef>
>
>
> If a user then really need to override "foo", he or she would simply
> write in build.xml something like
>
>
> <macrodef name="foo">
> <sequential>
> <echo> before original foo ..</echo>
>
> <c:foo /> <!-- assume framework in NS "c" />
>
> <echo> after original foo .. </echo>
> </sequential>
> </macrodef>
Can you do <c:foo/> without changes to Ant?
The problems I see with this:
* not idiomatic (no real problem, though)
* requires all targets to consist of a single macro definition
* becomes repetetive with little chance for reuse
Say I'd like to perform the same action before more than one target
<target name="my-before" before="foo,bar,baz">
<do-something/>
</target>
instead of
<macrodef name="foo">
<sequential>
<do-something/>
<c:foo/>
</sequential>
</macrodef>
<macrodef name="bar">
<sequential>
<do-something/>
<c:bar/>
</sequential>
</macrodef>
<macrodef name="baz">
<sequential>
<do-something/>
<c:baz/>
</sequential>
</macrodef>
* doesn't factor into the dependency calculation
taking the example from above, if all three targets foo, bar and baz
were executed in the same build, the dependencies of my-before would
only be executed once.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects
Posted by Wolfgang Häfelinger <wh...@epo.org>.
> So every concrete simple target like <target name="foo" depends="bar,
> baz" /> became
>
> <target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
> <target name="-foo" > ... </target>
> <target name="-pre-foo" />
> <target name="-post-foo" />
This looks pretty ugly this me!
I believe that this whole discussion focusses too much on targets
instead of macros. Macros are a very powerfull feature and they
deserve much more attention!
Why not simply:
<!-- === framework === -->
<target name="foo" depends="bar,baz" description="public foo target">
<foo />
</target>
<macrodef name="foo" >
<sequential>
<!-- to the foo thing -->
</sequential>
</macrodef>
If a user then really need to override "foo", he or she would simply
write in build.xml something like
<macrodef name="foo">
<sequential>
<echo> before original foo ..</echo>
<c:foo /> <!-- assume framework in NS "c" />
<echo> after original foo .. </echo>
</sequential>
</macrodef>
Notice that I'm only using the name "foo" and not "-post-foo" and all
your other names.
Regards,
Wolfgang Häfelinger
Research & Architecture | Dir. 2.7.0.2
European Patent Office
Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
Tel. +31 (0)70 340 4931
whaefelinger@epo.org
http://www.epo.org
"Dominique Devienne" <dd...@gmail.com>
14-01-2008 17:17
Please respond to
"Ant Developers List" <de...@ant.apache.org>
To
"Ant Developers List" <de...@ant.apache.org>
cc
Subject
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects
On 1/14/08, Stefan Bodewig <bo...@apache.org> wrote:
> "Dominique Devienne" <dd...@gmail.com> writes:
> Having something like before/after/around advices (where around is the
> same as an override that doesn't change the dependencies list) may
> suffice and leave overwriting the whole target definition to the worst
> case.
Thanks for reminding me of this issue Stefan. Indeed, something I
really didn't like about overriding the whole target, is that you had
to duplicate the dependency list as well...
Which is why I now remember that I now remember I used 4, not 3
targets, in the "abstract" build, the forth one being the target's own
content, separate from its dependency list:
So every concrete simple target like <target name="foo" depends="bar,
baz" /> became
<target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
<target name="-foo" > ... </target>
<target name="-pre-foo" />
<target name="-post-foo" />
in the "abstract" build. Override -foo to replace just the target
content, without it's dependency list. Or override foo to have
complete control, but in my experience it's -foo that needed
overriding, not foo.
Note though that unlike before and after, around isn't as
representative a name. When I thought about this issue a while back, I
thought of using a magic name such as "super" in the depends attribute
to refer to the overridden target's dependency list, similar to using
<super/> in the target's body to refer to the overridden target's task
list/content. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Stefan Bodewig <bo...@apache.org>.
"Dominique Devienne" <dd...@gmail.com> writes:
> On 1/14/08, Stefan Bodewig <bo...@apache.org> wrote:
>> "Dominique Devienne" <dd...@gmail.com> writes:
>> Having something like before/after/around advices (where around is the
>> same as an override that doesn't change the dependencies list) may
>> suffice and leave overwriting the whole target definition to the worst
>> case.
>
> Thanks for reminding me of this issue Stefan. Indeed, something I
> really didn't like about overriding the whole target, is that you had
> to duplicate the dependency list as well...
>
> Which is why I now remember that I now remember I used 4, not 3
> targets, in the "abstract" build, the forth one being the target's own
> content, separate from its dependency list:
I get away with two, but don't get the nice names you use.
<target name="ready-to-do-foo" depends="bar,baz"/>
<target name="foo" depends="-pre-foo">...</target>
and my overriding targets depend on the imported targets to get in the
correct place in the dependency chain. I.e. a -post-foo target as you
use it would be
<target name="foo" depends="imported:foo">...</target>
> Note though that unlike before and after, around isn't as
> representative a name.
In my case the names come from their usage in Common Lisp so they do
have some precedent. I agree that around doesn't really describe what
it does.
> When I thought about this issue a while back, I thought of using a
> magic name such as "super" in the depends attribute to refer to the
> overridden target's dependency list, similar to using <super/> in
> the target's body to refer to the overridden target's task
> list/content.
I don't have any problem with super as a magic target name, but I'm
still not convinced of <super/>. Hmm, maybe we should spawn of
separate threads for the different topics.
<super/> must in some way be taken into account when setting up the
dependency graph of the whole build file which makes it a different
beast from normal tasks. With before and after attributes on target
you wouldn't need <super/> anymore.
Stefan
--
http://stefan.samaflost.de/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Dominique Devienne <dd...@gmail.com>.
On 1/14/08, Stefan Bodewig <bo...@apache.org> wrote:
> "Dominique Devienne" <dd...@gmail.com> writes:
> Having something like before/after/around advices (where around is the
> same as an override that doesn't change the dependencies list) may
> suffice and leave overwriting the whole target definition to the worst
> case.
Thanks for reminding me of this issue Stefan. Indeed, something I
really didn't like about overriding the whole target, is that you had
to duplicate the dependency list as well...
Which is why I now remember that I now remember I used 4, not 3
targets, in the "abstract" build, the forth one being the target's own
content, separate from its dependency list:
So every concrete simple target like <target name="foo" depends="bar,
baz" /> became
<target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
<target name="-foo" > ... </target>
<target name="-pre-foo" />
<target name="-post-foo" />
in the "abstract" build. Override -foo to replace just the target
content, without it's dependency list. Or override foo to have
complete control, but in my experience it's -foo that needed
overriding, not foo.
Note though that unlike before and after, around isn't as
representative a name. When I thought about this issue a while back, I
thought of using a magic name such as "super" in the depends attribute
to refer to the overridden target's dependency list, similar to using
<super/> in the target's body to refer to the overridden target's task
list/content. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Stefan Bodewig <bo...@apache.org>.
"Dominique Devienne" <dd...@gmail.com> writes:
> On Jan 11, 2008 8:11 AM, Stefan Bodewig <bo...@apache.org> wrote:
>> "Gilles Scokart" <gs...@gmail.com> writes:
>>
>> > I never thought to overwrite macro to customize a generic build script. Can
>> > macro be overwritten?
>>
>> Sure, it's just another Ant task that has been defined.
>
> But my point is that most of the time, you never want to override
> things (macros or target), but augment them with some kind of pre or
> post processing.
Hey, I didn't say it was a good thing to do, I just pointed out that
technically you can override a macrodef'ed task just like any other
task.
> Peo's point of simply copy-pasting the "abstract" build code to
> fully override the target duplicates that code, and makes build
> maintenance all the more difficult.
I'm not convinced that we need something like this at the task level,
while I agree we need some better support for it at the target level.
Back during the Ant2 discussions we have been talking about adding AOP
like features to Ant at a well-defined "pointcut"s like target and
task invactions. This may be overkill, though.
Having something like before/after/around advices (where around is the
same as an override that doesn't change the dependencies list) may
suffice and leave overwriting the whole target definition to the worst
case.
Stefan
--
http://stefan.samaflost.de/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Dominique Devienne <dd...@gmail.com>.
On Jan 11, 2008 8:11 AM, Stefan Bodewig <bo...@apache.org> wrote:
> "Gilles Scokart" <gs...@gmail.com> writes:
>
> > I never thought to overwrite macro to customize a generic build script. Can
> > macro be overwritten?
>
> Sure, it's just another Ant task that has been defined.
But my point is that most of the time, you never want to override
things (macros or target), but augment them with some kind of pre or
post processing. Peo's point of simply copy-pasting the "abstract"
build code to fully override the target duplicates that code, and
makes build maintenance all the more difficult. That's the well known
issue with code generator and code wizards when it's done in a one-of
way. Copy-pasting a target content shows failure of the generic build
to be flexible, and should be the exception rather than the rule, and
actually frowned upon IMHO. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Stefan Bodewig <bo...@apache.org>.
"Gilles Scokart" <gs...@gmail.com> writes:
> I never thought to overwrite macro to customize a generic build script. Can
> macro be overwritten?
Sure, it's just another Ant task that has been defined.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Gilles Scokart <gs...@gmail.com>.
I never thought to overwrite macro to customize a generic build script. Can
macro be overwritten?
2008/1/10, Wolfgang Häfelinger <wh...@epo.org>:
>
> >> it is certainly something that already exists in the wild. Does it?
>
> It's called AntEpoline and lives currently in The Netherlands,
> especially here at the EPO in The Hague. Ca. 90% of our Java
> projects are using AntEpoline, the remaining mainly Maven I.
>
> Here's how a typical build file looks like:
>
> <project name="helloworld" xmlns:c="antlib:ant.epoline">
> <c:import />
>
> <dependencies>
> <dependency groupid="log4j" artefactid="log4j" version="1.2.13" />
> </dependencies>
>
> <macrodef name="package">
> <sequential>
> <!-- "original" packaging" -->
> <c:package />
> <!-- so something else -->
> </sequential>
> </macrodef>
> </project>
>
>
--
Gilles Scokart
RE: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects
Posted by Wolfgang Häfelinger <wh...@epo.org>.
>> it is certainly something that already exists in the wild. Does it?
It's called AntEpoline and lives currently in The Netherlands,
especially here at the EPO in The Hague. Ca. 90% of our Java
projects are using AntEpoline, the remaining mainly Maven I.
Here's how a typical build file looks like:
<project name="helloworld" xmlns:c="antlib:ant.epoline">
<c:import />
<dependencies>
<dependency groupid="log4j" artefactid="log4j" version="1.2.13" />
</dependencies>
<macrodef name="package">
<sequential>
<!-- "original" packaging" -->
<c:package />
<!-- so something else -->
</sequential>
</macrodef>
</project>
All the magic is done via tag <import>: generating standard
targets (like clean, compile, test and package) and importing
"extension points" (macros) for customization.
Such a customization is shown for target "package" (which does
nothing else than calling macro "package").
All a developer needs to do is to specify dependencies...
Xavier is absolut right in his reflections about Maven. It's so
easy for a developer to use it and you get all this nice things,
dependency management and all those pretty reports...
Regards,
Wolfgang Häfelinger
Research & Architecture | Dir. 2.7.0.2
European Patent Office
Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
Tel. +31 (0)70 340 4931
whaefelinger@epo.org
http://www.epo.org
"Gilles Scokart" <gs...@gmail.com>
10-01-2008 17:03
Please respond to
"Ant Developers List" <de...@ant.apache.org>
To
"'Ant Developers List'" <de...@ant.apache.org>
cc
Subject
RE: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects
I already thinked to something similar as well (after having re-written a
few time generic build scripts).
For me, one of the issues to solve is the problem of packaging a set of
reusable build script in a nice way. For that,
my idea was to use a "BAR" (Builder Archive). That would be a packaged jar
that would include a build script with the
life cycle, and some standard 'plug-in' builds scripts extending the life
cycle in a standard way, (and potentally also
the class for some task). That way, all you need to build is ant, the
bar, and your project build script that would set
some properties and include the right build files coming from the bar.
An other difficulty is to document those reusable build scripts. I have
already re-written a few reusable build
scripts, but I have to admit that I never managed to get the right level
of documentation for it.
Finally, I stopped my reflections, thinking that it is certainly something
that already exists in the wild. Does it?
Gilles
> -----Original Message-----
> From: Matt Benson [mailto:gudnabrsam@yahoo.com]
> Sent: jeudi 10 janvier 2008 16:12
> To: Ant Developers List
> Subject: Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for
java projects
>
> Xavier:
> I think it would be good to have a system that
> pretty much bundles alternatives for everything Maven
> provides, but without all the black magic that makes
> Maven difficult to customize. Basically antlibs for
> all parts of the Maven lifecycle, including,
> especially, Ivy. :) In fact, I already came up with
> my own name for this concept some time back:
> "Shaven". ;)
>
> -Matt
>
> --- Xavier Hanin <xa...@gmail.com> wrote:
>
> > Hi,
> >
> > It's been a long time since I'm thinking about this,
> > and thought it might be
> > interesting to share with you and see where the idea
> > can go.
> >
> > I see many developers adopt Maven because they want
> > a build system able to
> > provide common features with no effort. Most of them
> > don't want to spend
> > much time writing an Ant script, or have seen or
> > heard that maintaining Ant
> > build scripts is troublesome. So they choose to use
> > Maven only because it's
> > easy to use for common use cases: install, write a
> > simple pom of a few lines
> > or generate it using an archetype, and you're ready
> > to compile, test and
> > package your new project following the Maven
> > standard structure. They also
> > get dependency management for free, and with only a
> > few more effort they
> > have multi module builds, and some nice features
> > like code analysis,
> > coverage, and a set of report gathered in a web
> > site. That's really nice and
> > that's what I like about Maven.
> >
> > But Maven suffers from a lack of flexibility and
> > robustness IMHO. And later
> > the same people who first adopted Maven because of
> > its perceived ease of use
> > become frustrated when they need to tweek the system
> > to their own needs or
> > don't understand how the release plugin work. Then
> > some of them go back to
> > Ant, first having to go through a sometimes painful
> > road to describe their
> > whole build system in xml, especially if they aren't
> > Ant experts. Others try
> > to use new build tools like raven, buildr or others.
> >
> > I really like Ant, and think it is a very good basis
> > for robust and flexible
> > build systems. People with enough knowledge of Ant
> > can write very good build
> > systems, testable, maintainable and adaptable. But
> > you need to get your
> > hands dirty, and you need to get a good knowledge of
> > some of the mechanisms
> > which can make an Ant based build system manageable:
> > import, scripts and
> > scriptdef, macrodef, presetdef, and so on.
> >
> > Hence I'm wondering if it wouldn't be a good idea to
> > package a set of Ant
> > build files, providing all the basic features of a
> > build system for java
> > projects: dependency management, compilation,
> > testing and packaging, plus
> > maybe some more advanced features like code coverage
> > and code auditing.
> > Multi module build support would be nice to have
> > too. Then someone needing
> > only those features could simply have a build file
> > per project mostly
> > consisting of a single import of the common build
> > file provided. Some
> > needing more could provide plugins to the build
> > system itself. Some needing
> > to tweak the system could simply override some
> > target definitions or
> > properties. Others with very specific needs could
> > simply use the build
> > scripts as examples or basis.
> >
> > I guess most people on this list know the benefit of
> > having such a build
> > system and how well it scales, and most of us
> > already have developed such a
> > set of build files. But providing the basis of such
> > a good build system well
> > packaged and documented could improve the Ant
> > community IMO. With some
> > efforts from our community we could end up with
> > something interesting pretty
> > easily. Most of us don't have much time, but we
> > probably already have a good
> > basis from the build files we work with around, and
> > if this can be done in a
> > community effort it could remain affordable in terms
> > of time required.
> >
> > So, what do you think? Do you think this would be
> > useful? Would you be
> > interested in contributing? Do you think a new Ant
> > sub project would be a
> > good fit?
> >
> > Xavier
> > --
> > Xavier Hanin - Independent Java Consultant
> > http://xhab.blogspot.com/
> > http://ant.apache.org/ivy/
> > http://www.xoocode.org/
> >
>
>
>
>
____________________________________________________________________________________
> Never miss a thing. Make Yahoo your home page.
> http://www.yahoo.com/r/hs
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Gilles Scokart <gs...@gmail.com>.
I already thinked to something similar as well (after having re-written a few time generic build scripts).
For me, one of the issues to solve is the problem of packaging a set of reusable build script in a nice way. For that,
my idea was to use a "BAR" (Builder Archive). That would be a packaged jar that would include a build script with the
life cycle, and some standard 'plug-in' builds scripts extending the life cycle in a standard way, (and potentally also
the class for some task). That way, all you need to build is ant, the bar, and your project build script that would set
some properties and include the right build files coming from the bar.
An other difficulty is to document those reusable build scripts. I have already re-written a few reusable build
scripts, but I have to admit that I never managed to get the right level of documentation for it.
Finally, I stopped my reflections, thinking that it is certainly something that already exists in the wild. Does it?
Gilles
> -----Original Message-----
> From: Matt Benson [mailto:gudnabrsam@yahoo.com]
> Sent: jeudi 10 janvier 2008 16:12
> To: Ant Developers List
> Subject: Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
>
> Xavier:
> I think it would be good to have a system that
> pretty much bundles alternatives for everything Maven
> provides, but without all the black magic that makes
> Maven difficult to customize. Basically antlibs for
> all parts of the Maven lifecycle, including,
> especially, Ivy. :) In fact, I already came up with
> my own name for this concept some time back:
> "Shaven". ;)
>
> -Matt
>
> --- Xavier Hanin <xa...@gmail.com> wrote:
>
> > Hi,
> >
> > It's been a long time since I'm thinking about this,
> > and thought it might be
> > interesting to share with you and see where the idea
> > can go.
> >
> > I see many developers adopt Maven because they want
> > a build system able to
> > provide common features with no effort. Most of them
> > don't want to spend
> > much time writing an Ant script, or have seen or
> > heard that maintaining Ant
> > build scripts is troublesome. So they choose to use
> > Maven only because it's
> > easy to use for common use cases: install, write a
> > simple pom of a few lines
> > or generate it using an archetype, and you're ready
> > to compile, test and
> > package your new project following the Maven
> > standard structure. They also
> > get dependency management for free, and with only a
> > few more effort they
> > have multi module builds, and some nice features
> > like code analysis,
> > coverage, and a set of report gathered in a web
> > site. That's really nice and
> > that's what I like about Maven.
> >
> > But Maven suffers from a lack of flexibility and
> > robustness IMHO. And later
> > the same people who first adopted Maven because of
> > its perceived ease of use
> > become frustrated when they need to tweek the system
> > to their own needs or
> > don't understand how the release plugin work. Then
> > some of them go back to
> > Ant, first having to go through a sometimes painful
> > road to describe their
> > whole build system in xml, especially if they aren't
> > Ant experts. Others try
> > to use new build tools like raven, buildr or others.
> >
> > I really like Ant, and think it is a very good basis
> > for robust and flexible
> > build systems. People with enough knowledge of Ant
> > can write very good build
> > systems, testable, maintainable and adaptable. But
> > you need to get your
> > hands dirty, and you need to get a good knowledge of
> > some of the mechanisms
> > which can make an Ant based build system manageable:
> > import, scripts and
> > scriptdef, macrodef, presetdef, and so on.
> >
> > Hence I'm wondering if it wouldn't be a good idea to
> > package a set of Ant
> > build files, providing all the basic features of a
> > build system for java
> > projects: dependency management, compilation,
> > testing and packaging, plus
> > maybe some more advanced features like code coverage
> > and code auditing.
> > Multi module build support would be nice to have
> > too. Then someone needing
> > only those features could simply have a build file
> > per project mostly
> > consisting of a single import of the common build
> > file provided. Some
> > needing more could provide plugins to the build
> > system itself. Some needing
> > to tweak the system could simply override some
> > target definitions or
> > properties. Others with very specific needs could
> > simply use the build
> > scripts as examples or basis.
> >
> > I guess most people on this list know the benefit of
> > having such a build
> > system and how well it scales, and most of us
> > already have developed such a
> > set of build files. But providing the basis of such
> > a good build system well
> > packaged and documented could improve the Ant
> > community IMO. With some
> > efforts from our community we could end up with
> > something interesting pretty
> > easily. Most of us don't have much time, but we
> > probably already have a good
> > basis from the build files we work with around, and
> > if this can be done in a
> > community effort it could remain affordable in terms
> > of time required.
> >
> > So, what do you think? Do you think this would be
> > useful? Would you be
> > interested in contributing? Do you think a new Ant
> > sub project would be a
> > good fit?
> >
> > Xavier
> > --
> > Xavier Hanin - Independent Java Consultant
> > http://xhab.blogspot.com/
> > http://ant.apache.org/ivy/
> > http://www.xoocode.org/
> >
>
>
>
> ____________________________________________________________________________________
> Never miss a thing. Make Yahoo your home page.
> http://www.yahoo.com/r/hs
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Posted by Matt Benson <gu...@yahoo.com>.
Xavier:
I think it would be good to have a system that
pretty much bundles alternatives for everything Maven
provides, but without all the black magic that makes
Maven difficult to customize. Basically antlibs for
all parts of the Maven lifecycle, including,
especially, Ivy. :) In fact, I already came up with
my own name for this concept some time back:
"Shaven". ;)
-Matt
--- Xavier Hanin <xa...@gmail.com> wrote:
> Hi,
>
> It's been a long time since I'm thinking about this,
> and thought it might be
> interesting to share with you and see where the idea
> can go.
>
> I see many developers adopt Maven because they want
> a build system able to
> provide common features with no effort. Most of them
> don't want to spend
> much time writing an Ant script, or have seen or
> heard that maintaining Ant
> build scripts is troublesome. So they choose to use
> Maven only because it's
> easy to use for common use cases: install, write a
> simple pom of a few lines
> or generate it using an archetype, and you're ready
> to compile, test and
> package your new project following the Maven
> standard structure. They also
> get dependency management for free, and with only a
> few more effort they
> have multi module builds, and some nice features
> like code analysis,
> coverage, and a set of report gathered in a web
> site. That's really nice and
> that's what I like about Maven.
>
> But Maven suffers from a lack of flexibility and
> robustness IMHO. And later
> the same people who first adopted Maven because of
> its perceived ease of use
> become frustrated when they need to tweek the system
> to their own needs or
> don't understand how the release plugin work. Then
> some of them go back to
> Ant, first having to go through a sometimes painful
> road to describe their
> whole build system in xml, especially if they aren't
> Ant experts. Others try
> to use new build tools like raven, buildr or others.
>
> I really like Ant, and think it is a very good basis
> for robust and flexible
> build systems. People with enough knowledge of Ant
> can write very good build
> systems, testable, maintainable and adaptable. But
> you need to get your
> hands dirty, and you need to get a good knowledge of
> some of the mechanisms
> which can make an Ant based build system manageable:
> import, scripts and
> scriptdef, macrodef, presetdef, and so on.
>
> Hence I'm wondering if it wouldn't be a good idea to
> package a set of Ant
> build files, providing all the basic features of a
> build system for java
> projects: dependency management, compilation,
> testing and packaging, plus
> maybe some more advanced features like code coverage
> and code auditing.
> Multi module build support would be nice to have
> too. Then someone needing
> only those features could simply have a build file
> per project mostly
> consisting of a single import of the common build
> file provided. Some
> needing more could provide plugins to the build
> system itself. Some needing
> to tweak the system could simply override some
> target definitions or
> properties. Others with very specific needs could
> simply use the build
> scripts as examples or basis.
>
> I guess most people on this list know the benefit of
> having such a build
> system and how well it scales, and most of us
> already have developed such a
> set of build files. But providing the basis of such
> a good build system well
> packaged and documented could improve the Ant
> community IMO. With some
> efforts from our community we could end up with
> something interesting pretty
> easily. Most of us don't have much time, but we
> probably already have a good
> basis from the build files we work with around, and
> if this can be done in a
> community effort it could remain affordable in terms
> of time required.
>
> So, what do you think? Do you think this would be
> useful? Would you be
> interested in contributing? Do you think a new Ant
> sub project would be a
> good fit?
>
> Xavier
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/
>
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org