Q for Mike Clark: Project Directory Structure

Dear Mike,

A couple of days ago I had to reconsider my
original choice for project directory
structure which I had based on the structure
proposed in the paper 'Ant in anger'.

This change of structure was 'forced' in order
to facilitate the checking out of the project
in the IDE we're using at work. Now it matches
the default naming scheme that the IDE uses,
and therefore there is less fiddling around with
the settings each time a project is checked out.

Project directory structure is essential and
company wide the same structure allows for
an ordered administration. What are your tips
with respect to this issue?

Cheers,

Gian Franco

[ September 21, 2004: Message edited by: Gian Franco Casula ]
[ September 21, 2004: Message edited by: Bear Bibeault ]

Originally posted by Gian Franco Casula:
Project directory structure is essential and
company wide the same structure allows for
an ordered administration. What are your tips
with respect to this issue?

Well, it's a shame you had to conform your project structure around an IDE. I'd prefer to have the structure suited for humans rather than machines.

In terms of fiddling around each time the project is checked out, Eclipse, for example, generates a .classpath file with directory references that are relative to the project's root directory. This means you can check in the .classpath file and everyone on the project who uses Eclipse can share the same file. That is, when you check out the project and load it into Eclipse, you don't have to fiddle with anything.

In the book, I use this project directory structure:

This has worked quite well for me. It keeps my tests separated from my production source files, but not too far away. Using Megg, a simple directory templating tool, I created a template for the directory structure in the book. It's useful for creating the same, consistent structure each time you start a new project. You can read about it and download the template at:

http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Build/ProjectTemplate.rdoc

Consistency is the key, and there's no "right" structure for every project. So please feel free to alter the template to match your company's directory structure of choice.

I hope those are the types of tips you were looking for. If not, please ask again.

Mike

[ September 21, 2004: Message edited by: Mike Clark ]
[ September 21, 2004: Message edited by: Mike Clark ]

I'll second Mike's tips. Before reading his book, I was using something close to what he presents. After reading his book, I combined his best practices with what I was using for a very nice layout, and I've used Megg to make it easy to begin each new project. The book, the link he provided and knowledge of what works well in your environment are all that you need to automate the layout of new projects forevermore.

Craig

Originally posted by Mike Clark:
Well, it's a shame you had to conform your project structure around an IDE. I'd prefer to have the structure suited for humans rather than machines.

Agreed in general, though sometimes it's the most pragmatic thing to do.

For example, our project is comprised of quite a bunch of CVS modules/Eclipse projects. Until recently, they were organized hierarchically (with the leaves being the actual modules):

Problem was: when creating a new Eclipse workspace, you had to manually specify the directory for each module. When using a Team Project Set, you had to *move* the projects to the correct folders. With the typical size of our workspaces, this alone could take hours!

Now that we are using a flat directory structure, creating a new workspace is a no-brainer...