used. And I think people who maintain build system like to see how the build
magic". But there are solutions to provide both good packaging and easy
> 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@...
>
>