ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <j...@socialchange.net.au>
Subject Re: [POLL] jakarta-ant-templates (Generic Ant-based project templates)
Date Wed, 21 Nov 2001 01:22:42 GMT
On Tue, Nov 20, 2001 at 06:08:14PM +0100, Rolf Katzenberger wrote:
> Hello Jeff,
> 
> On Mon, 19 Nov 2001 21:36:39 +1100, Jeff Turner
> <jeff@socialchange.net.au> wrote:
> 
> >I was wondering, how do people feel about developing "common",
> >"universal", "generic" build.xml scripts for common needs?
> >
> >I have hordes of mini-projects on the go, the end result of each is:
> > - a jar file
> > - some javadocs
> > - some config files
> > - the above all packaged as a .tar.gz and .zip
> 
> The same goes for me, maybe my hordes are a bit smaller. ;-)
> 
> >My very first build.xml was copied from an Apache project, and hacked to
> >meet my needs. Subsequent projects were all cut-and-paste affairs. Over
> >time, as I noticed that most projects are pretty similar, I formalized
> >this by creating a "generic" build.xml, and an associated template
> >project structure.
> >
> >This system has been working nicely for many months.  Project-specific
> >customizations are all kept to an external build.properties file, which
> >allows the build.xml to evolve independently.
> 
> This is an interesting approach. Did you manage to put all project
> specifics into properties files?

Yes, but possibly I only managed it because my problem domain is small. There
is one useful trick here: declare a 'main' target which is the default, and
then call others from that.  Then you can have build.properties declare it's
default target ('jar' in most projects, 'dist' in others). Having a
guaranteed-present 'main' target also means you can type 'ant clean main' on
any project, and have it work, rather than the slower 'ant clean ; ant'.


> Sometimes I needed additional
> targets, which is why I did not manage to maintain a truly generic
> build.xml so far. What I did in the past was to place *developer*
> specifics into build.properties, since most of my colleagues have
> their own ideas where to install their software.
> 
> [snip]
> >Of course, what constitutes a "good" build.xml is extremely subjective,
> >and even if the scope is strictly regulated I doubt we could reach
> >"consensus". Multiple solutions are fine with me. But *whatever* we can
> >achieve together is better than what we can achieve independently.
> >
> >The big winner should be newcomers, who just want to get their code
> >building. They can now download a "turnkey" solution; plug your code in
> >and go :) Ant gains new users, and today's newbies are tomorrow's
> >contributors.
> >
> >So what I'd like to know from y'all:
> >
> >1) Does this sound workable? (and for what definition of "this"?)
> 
> Yes.
> 
> >2) Do you have a generic build system to contribute?
> >
> >
> >If there's critical mass, let's wander off and form a sourceforge
> >project to discuss it; come up with categories, associated solutions,
> >document pros and cons; then come back here and twist arms until they
> >let us form a jakarta-ant-template subproject :)
> 
> Well... ummm... :o) I already started such a sourceforge project a
> while ago, Ant Heap (http://sourceforge.net/projects/antheap) -
> currently in pre-alpha, but already a tiny appetizer release is
> downloadable.

Wohoo :) Would my build system fit in here?


> My goal was to provide copy&paste ready build scripts for
> not-so-trivial challenges that are useful for people who do not really
> (need to) know in-depth how things in build.xml work.
> 
> >To get the ball rolling, I've put up my attempt at:
> >
> >http://opensource.socialchange.net.au/build/
> >
> >I've attached -projecthelp output at the end, to give you a brief idea of what
> >it does. But let's discuss the general concept on this thread, rather than my
> >implementation.
> >
> >Looking forward to everyone's comments :)
> 
> Downloaded this and liked it. Here we go:
> 
> - usage of something like dependencies.xml is a good idea; I also like
> the concept of having sub-buildfiles with well-defined names

dependencies.xml was mostly an experiment, but something similar using CVS
would be useful. I'd also like to find a way to list dependencies in
build.properties.

Btw, if you want to see an *inspired* build system, have a look at
jakarta-taglibs' :) Each subproject script 'inherits' from it's owner, and each
target has 'pre' and 'post' targets (also overridable).. it's very cool.

> - as you already mentioned, opinions vary what constitutes a "good"
> build.xml; personally, I don't feel like *imposing* certain styles of
> e.g. unit testing or certain tools (CVS is not used everywhere), which
> is why I'd prefer "building" blocks in smaller sample build.xml files
> that give the users freedom of choice. Of course, all build.xml files
> must be compatible with each other, then.

Sounds sensible. I've always relied on the example snippets in the docs.
Perhaps we could expand on those?

OTOH, there's also the architectural issues that are only become apparent when
trying to build the full thing. Issues like property naming (I still haven't
figured that out), property granularity (when can you safely just 'hardcode' a
path), use of 'subtargets' etc. Then there's also all the ways that the project
filesystem structure affects the build file. If you don't separate runtime jars
(src/lib) from compile-time jars (/lib), you need hacky logic to separate them
when building distros, .wars etc. Same with .html and .properties files in
src/java/.

> - in several places in build.xml, the dot '.' was used for starting
> relative paths; im not sure whether ${basedir} wwas the better choice
> for this?

I wish I'd written better CVS logs at the time ;P I originally had it
${basedir}, and changed for some good reason that I've now forgotten. Something
was unhappy about the absolute path, and I concluded that relative is more
flexible (you can always prepend ${basedir}).

> - copy-resources copies a whole directory; maybe copying only specific
> file patterns prevents one from deploying unwanted artifacts (backup
> files of graphics programs, HTML editors, and the like)?

Yep, but I've no idea what those file patterns are.

> - the javadocs target has a hardcoded copyright year (2001) that is
> placed e.g. into the window title. Maybe the copyright of javadocs
> always pertains to the year of the creation of the docs, so we could
> make use of tstamps date formatting capabilities ("YYYY") to create a
> property for the 4-digit years?

I've got hardcoded "Copyright Social Change Online" in various places.. will
fix now. Yes, timestamps can be used to much greater effect.

> Seen from a general point of view, would you say that building
> smaller, reusable build.xmls that highlight just one aspect would
> work? Or is it preferrable to have a (big) generic build.xml with e.g.
> hooks for extensions? Or are there even better options?

As for 'hooks for extensions', do you like my build-docs.xml system? :) Usually
'docs' builds javadocs, but if there's a build-docs.xml file present, that gets
invoked.

In general, I think both are useful. I suspect many people have a small
personal collection of build.xml experiments, useful tricks and other snippets.
I'm sure these could be useful to others (if appropriately documented). But for
all the reasons outlined above, I think you need to go further and give'em a
full working system to play with :)


--Jeff

> Best regards,
> Rolf

--
To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>


Mime
View raw message