[DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[limbicsystem]

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/

[Gilles Scokart]

2008/2/11, limbicsystem <limbicsystem@...>:
>
>
> 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

[Xavier Hanin]

On Feb 11, 2008 8:35 PM, limbicsystem <limbicsystem@...> 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@...
> For additional commands, e-mail: dev-help@...
>
>

--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

[kkckkc]

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

[Ittay Dror]

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:


<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/

[ddevienne]

On Wed, Apr 30, 2008 at 1:19 AM, Ittay Dror <ittay.dror@...> 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@...
For additional commands, e-mail: dev-help@...

[Gilles Scokart]

2008/4/30 Ittay Dror <ittay.dror@...>:

>
>  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@...
For additional commands, e-mail: dev-help@...

[Ittay Dror]

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

[Ittay Dror]

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