ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon David Kelly <>
Subject Re: "Blueprints" for Ant Templates?
Date Wed, 19 Mar 2003 07:46:57 GMT
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!"

View raw message