ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject AW: "Blueprints" for Ant Templates?
Date Wed, 19 Mar 2003 08:03:54 GMT
Sounds good.

In my actual project I have refactored my buildfile and created some
XML-snippets (Start the code generator, start the editor with certain files,
initialize, create HTML from java source, junitreport, start Rational Rose
Web Publisher, ...) which I included via XML-entity.

During refactorization I found a pattern (I call it PreIfDoPost :-) and
implemented it: I have four targets, two of them are optional:
name.pre (optional, in my buildfile)
	I can write here some stuff to some work before execution.
name.condition (in the snippet)
	Calls the name.pre if that target is present.
	Here I check if all conditions passed for execution the real
	work (e.g. is the WebPublisher present?)
name (in the snippet)
	Here is the work. This target is the one I call. It is called
	only if condition is passed. After work it calles
	if that target exists. (optional, in my buildfile)
	Here I can do some stuff after execution (e.g. write a new
	main page of the generated HTML from WebPublisher).

So I can use these snippets in multiple projects without thinking about it
each time.

Disadvantage: I use <script> for calling Pre/Post, so it depends on BSF. And
it can´t resolve dependencies from Pre/Post! (so name.pre and must
not have a depends-attribute)

If someone want I can post the snippets.

Jan Matèrne

-----Ursprüngliche Nachricht-----
Von: Simon David Kelly []
Gesendet am: Mittwoch, 19. März 2003 08:47
An: Ant Users List
Betreff: Re: "Blueprints" for Ant Templates?

Greg, Paul et al,

I think form what you are saying, you want a project creator that you 
can run at the start of the project life-cycle, prior to the 
requirements stage (Be fore you really know what you are going to 
develop).  And this builder can have a collection of project types, as 
in the JBoss example, that will then give you a required layout.

Having developed several medium size projects (two or three man teams) I 
have come up with a couple of "rules of thumb" that can help in 
structuring a project layout.

1)  Don't structure it till you know exactly what it is your developing. 
 I like at least half the use-cases fully developed on paper prior to 
coding a single line and all of the requirements.  You know then at 
least half your code, and where reuse can be applied.  You also have a 
naming strategy that will help with the layout.

2)  Only one person structures the layout, and use a checkout style cvs. 
 This stops people who think there good and aren't from c**king up your 
structure.  It happens, and more often than not.  And above all else 
DOCUMENT the structure, preferably in plain english (language of your 
choice :-))

3)  Use real names (not too much of a problem these days as most Java 
developers are taught to be descriptive with class names and methods), I 
have seen project structures with dirs called inc/ and seq/  (Initialize 
Network Communications & Standard (e)Sql Queries [Yes this person 
thought sql started with an 'e']).  This is also very helpful to those 
who will be maintaining your code after you retire to the Hamptons.

4)  If you are extending a framework application (Like JBoss or Struts), 
get the template they supply and use it's structure (they both have 
one).  The applications generally need certain files/file types in a 
specific location, if you follow their methodology you will eliminate 
quite a few problems from the word go.

5)  Don't get stuck thinking that there has to be a certain structure 
for every project of a specific type [apart from point 4].  The 
methodology of programming and project development changes year to year, 
as non programming academics theorize new ones.  Just because they have 
the Dr. in front of there names does not make them right!  Pick a 
structure that suits your team, not the latest ideas, a lot of them can 
(and are) wrong for your way of working.

This is, of course, just my own opinion and way of working.  It works 
for me and cuts down on the number of times I shout "Where the **** did 
that class go!!", and the amount of times the project needs to be 
restructured because one bit will not fit without a full re-code (Done 
it once, NEVER again!!)

Remember that templates can be a good thing for small projects, and 
beginners to an application.  They rarely work for very large scale 
projects, so choose something that fits what you want .  It wont take 
more than a morning, if you follow point one, and you will know right 
from the start what you have and where it goes.

Just my 2 cents, but worth every penny ;-)



"If it can't be done on the command line,
it ain't worth doing!"

To unsubscribe, e-mail:
For additional commands, e-mail:

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