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

[Xavier Hanin]

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/

[Matt Benson]

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

      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page.
http://www.yahoo.com/r/hs

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Gilles Scokart]

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@...]
> 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 <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/
> >
>
>
>
>       ____________________________________________________________________________________
> Never miss a thing.  Make Yahoo your home page.
> http://www.yahoo.com/r/hs
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Dominique Devienne-2]

On Jan 10, 2008 8:25 AM, Xavier Hanin <xavier.hanin@...> 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@...
For additional commands, e-mail: dev-help@...

[Xavier Hanin]

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 <gscokart@...> 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@...]
> > 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 <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/
> > >
> >
> >
> >
> >
> ____________________________________________________________________________________
> > Never miss a thing.  Make Yahoo your home page.
> > http://www.yahoo.com/r/hs
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
>
>
> ---------------------------------------------------------------------
> 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/

[Xavier Hanin]

On Jan 10, 2008 4:12 PM, Matt Benson <gudnabrsam@...> 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 <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/
> >
>
>
>
>
>  ____________________________________________________________________________________
> Never miss a thing.  Make Yahoo your home page.
> http://www.yahoo.com/r/hs
>
> ---------------------------------------------------------------------
> 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/

[Wolfgang Häfelinger]

>> 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. [phone]
whaefelinger@...
http://www.epo.org




"Gilles Scokart" <gscokart@...>
10-01-2008 17:03
Please respond to
"Ant Developers List" <dev@...>


To
"'Ant Developers List'" <dev@...>
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@...]
> 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 <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/
> >
>
>
>
>

____________________________________________________________________________________
> Never miss a thing.  Make Yahoo your home page.
> http://www.yahoo.com/r/hs
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Xavier Hanin]

On Jan 10, 2008 5:13 PM, Dominique Devienne <ddevienne@...> wrote:

> On Jan 10, 2008 8:25 AM, Xavier Hanin <xavier.hanin@...> 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@...
> 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/

[Xavier Hanin]

On Jan 10, 2008 5:29 PM, Wolfgang Häfelinger <whaefelinger@...> 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/

[Wolfgang Häfelinger]

>> 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. [phone]
whaefelinger@...
http://www.epo.org




"Xavier Hanin" <xavier.hanin@...>
10-01-2008 18:04
Please respond to
"Ant Developers List" <dev@...>


To
"Ant Developers List" <dev@...>
cc

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






On Jan 10, 2008 5:29 PM, Wolfgang Häfelinger <whaefelinger@...> 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]

On Jan 10, 2008 6:18 PM, Wolfgang Häfelinger <whaefelinger@...> 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. [phone]
> whaefelinger@...
> http://www.epo.org
>
>
>
>
> "Xavier Hanin" <xavier.hanin@...>
> 10-01-2008 18:04
> Please respond to
> "Ant Developers List" <dev@...>
>
>
> To
> "Ant Developers List" <dev@...>
> cc
>
> Subject
> Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
> projects
>
>
>
>
>
>
> On Jan 10, 2008 5:29 PM, Wolfgang Häfelinger <whaefelinger@...> 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/