ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Date Thu, 10 Jan 2008 20:13:13 GMT
On Jan 10, 2008 7:21 PM, Peter Arrenbrecht <peter.arrenbrecht@gmail.com>
wrote:

> I like the idea very much. One crucial aspect, however, would be to
> provide a graceful path from using the prepackaged building blocks
> towards inlining and customizing them. If this is not possible, the
> thing will most likely start feeling as unwieldy as maven itself in a
> while. The advantage of ant would really come into play when users can
> pull in the building blocks and immediately see how everything was
> done, learn from that, and then tweak to their liking.

Exactly.


> Providing
> override hooks is all well and good, but that is still basically the
> very controlled and rigit maven approach, I think.

It depends on what you accept to do in your override. If the build system
somewhat relies on Ant import mechanism, you are able to override  any
target defined by the build system. In the end if you have something very
specific the worst that could happen is override everything, making the
build system useless except it first provided a structure. But at least you
are always free, which is not the case with maven.

It's like the
> difference between an interpreter and a code generator. IIRC, in Rails
> you normally get interpretation (on the fly code generation, in fact),
> but you can always switch to full blown code generation which you can
> then inspect and tweak. I think that is part of the reason for its
> success. It makes the whole thing transparent, but let's people stick
> to the standard where that suffices.

Interesting comparison, not sure how it could be applied to the build system
though.

Xavier


>
>
> -peo
>
> On Jan 10, 2008 3:25 PM, Xavier Hanin <xavier.hanin@gmail.com> wrote:
> > Hi,
> >
> > It's been a long time since I'm thinking about this, and thought it
> might be
> > interesting to share with you and see where the idea can go.
> >
> > I see many developers adopt Maven because they want a build system able
> to
> > provide common features with no effort. Most of them don't want to spend
> > much time writing an Ant script, or have seen or heard that maintaining
> Ant
> > build scripts is troublesome. So they choose to use Maven only because
> it's
> > easy to use for common use cases: install, write a simple pom of a few
> lines
> > or generate it using an archetype, and you're ready to compile, test and
> > package your new project following the Maven standard structure. They
> also
> > get dependency management for free, and with only a few more effort they
> > have multi module builds, and some nice features like code analysis,
> > coverage, and a set of report gathered in a web site. That's really nice
> and
> > that's what I like about Maven.
> >
> > But Maven suffers from a lack of flexibility and robustness IMHO. And
> later
> > the same people who first adopted Maven because of its perceived ease of
> use
> > become frustrated when they need to tweek the system to their own needs
> or
> > don't understand how the release plugin work. Then some of them go back
> to
> > Ant, first having to go through a sometimes painful road to describe
> their
> > whole build system in xml, especially if they aren't Ant experts. Others
> try
> > to use new build tools like raven, buildr or others.
> >
> > I really like Ant, and think it is a very good basis for robust and
> flexible
> > build systems. People with enough knowledge of Ant can write very good
> build
> > systems, testable, maintainable and adaptable. But you need to get your
> > hands dirty, and you need to get a good knowledge of some of the
> mechanisms
> > which can make an Ant based build system manageable: import, scripts and
> > scriptdef, macrodef, presetdef, and so on.
> >
> > Hence I'm wondering if it wouldn't be a good idea to package a set of
> Ant
> > build files, providing all the basic features of a build system for java
> > projects: dependency management, compilation, testing and packaging,
> plus
> > maybe some more advanced features like code coverage and code auditing.
> > Multi module build support would be nice to have too. Then someone
> needing
> > only those features could simply have a build file per project mostly
> > consisting of a single import of the common build file provided. Some
> > needing more could provide plugins to the build system itself. Some
> needing
> > to tweak the system could simply override some target definitions or
> > properties. Others with very specific needs could simply use the build
> > scripts as examples or basis.
> >
> > I guess most people on this list know the benefit of having such a build
> > system and how well it scales, and most of us already have developed
> such a
> > set of build files. But providing the basis of such a good build system
> well
> > packaged and documented could improve the Ant community IMO. With some
> > efforts from our community we could end up with something interesting
> pretty
> > easily. Most of us don't have much time, but we probably already have a
> good
> > basis from the build files we work with around, and if this can be done
> in a
> > community effort it could remain affordable in terms of time required.
> >
> > So, what do you think? Do you think this would be useful? Would you be
> > interested in contributing? Do you think a new Ant sub project would be
> a
> > good fit?
> >
> > Xavier
> > --
> > Xavier Hanin - Independent Java Consultant
> > http://xhab.blogspot.com/
> > http://ant.apache.org/ivy/
> > http://www.xoocode.org/
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>


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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message