[evla-sw-discuss] code organization

[Brian Truitt]

Bryan Butler wrote:
> so i had a look at this.  boy, their documentation leaves a bit to be desired 
> (maybe i'm supposed to know this, but what the hell is supposed to go in 
> src/site?  and what is the difference between sources and resources?).


src is source code, resources is things like hibernate config  files, 
the log4j config files, anything (for java) that ends in .properties 
pretty much. When you build a webapp, these files are automatically 
placed in your classpath (i.e. the WEB-INF/classes/ directory) so you 
can get at them in java.lang.Class.getResource(...).

The src/site directory holds the project's website and can be 
automatically generated by maven as well. I don't think we necessarily 
need this feature.

I'm not sure where the latex files go, but the target directory is blown 
away by maven when you do a clean rebuild, so it may or may not be a 
good spot, I don't know.

As far a trunk and branch development goes, I like developing on the 
"trunk" and then when a release comes along, create a tag in the tags 
directory. If we just had stable and devel directories, we'd only easily 
be able to get at the latest stable release. Previous stable releases 
would be harder to come by unless we tagged them...at which point we 
don't necessarily need the "stable" directory at all.

I suppose we could develop on the devel branch, when it's stable and 
ready for release, merge it into the stable branch, and then tag the new 
stable branch as well. This way we have tagged release AND have an easy 
checkout if we want to check out the most recent stable release without 
having to know what version (or tag name) that corresponds to. We can 
also accomplish this by making the stable directory a link in the 
repository to the most recent tag for that project. The link would have 
to be updated every time we tagged, but it is a symlink so changing one 
would change the other (although, theoretically we shouldn't be changing 
a tag or the stable branch I guess).

And lastly, I think NOT porting the whole revision history from CVS, and 
just keeping the old cvs repository is the friendliest and least error 
prone approach.

I'm going to end up as verbose as Butler here if I'm not careful...

Brian