[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@...

[ddevienne]

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/

[Peter Arrenbrecht]

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

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

[kermitt]

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 ?

[Xavier Hanin]

On Jan 10, 2008 7:21 PM, Peter Arrenbrecht <peter.arrenbrecht@...>
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 <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/
> >
>
> ---------------------------------------------------------------------
> 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 8:16 PM, kermitt <herve.bourzeix@...> 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@...
> 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/

[ddevienne]

On Jan 10, 2008 2:13 PM, Xavier Hanin <xavier.hanin@...> wrote:

> On Jan 10, 2008 7:21 PM, Peter Arrenbrecht <peter.arrenbrecht@...>
> > 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@...
For additional commands, e-mail: dev-help@...

[Xavier Hanin]

On Jan 10, 2008 9:33 PM, Dominique Devienne <ddevienne@...> wrote:

> On Jan 10, 2008 2:13 PM, Xavier Hanin <xavier.hanin@...> wrote:
> > On Jan 10, 2008 7:21 PM, Peter Arrenbrecht <peter.arrenbrecht@...>
> > > 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@...
> 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/

[Bruce Atherton]

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

[kermitt]

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 <[e-mail]> 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: [e-mail]
> For additional commands, e-mail: [e-mail]
>
>


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

[Xavier Hanin]

On Jan 10, 2008 10:20 PM, Bruce Atherton <bruce@...> 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@...
> 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/