How should I lay out my repository?

Question

I'm moving an application out of an svn repository it shares with a bunch of other stuff into its own, brand new one. So, I have a chance to make a fresh start with layout.

The app itself has two components - a reasonably standard Java webapp, that talks to a database, and a backend component, also Java, that polls the db, and kicks off long-running processing tasks based on what it finds - essentially, the DB is being used as a queue. The code is broken up into three packages:

1. org.blah.common - code, such as DAOs, that is shared between web app and back end
2. org.blah.webapp - The web app; this depends on org.blah.common, and builds out to a .war file.
3. org.blah.backend - The back end process; this depends on org.blah.common, and builds out to a tar file containing a jar and some scripts.

I'd also like to get other bits of tomcat and apache config into svn as well.

Right now, all three packages are in svn under a src dir, and there's an ant script with different targets that build the different parts. It's all a bit scrappy - the svn:ignore property has gotten quite big, and it's not immediately apparent that the scripts in one dir are related to the code in some package down under src, while those in another are for starting and stopping tomcat.

I'm drawn to the maven standard directory layout, but I've not used it before. I've come up with this:

common/
    src/
        main/
            java/
            resources/
        test/
            java/
            resources/
    target/    # Not checked in
        common.jar
webapp/
    src/
        main/
            java/
            resources/
            webapp/
        test/
            java/
            resources/
    target/    # Not checked in
        webapp.war
backend/
    src/
        main/
            java/
            perl/
            resources/
        test/
            java/
            resources/
    target/    # Not checked in
        backend.tar
infra/
    tomcat/
        bin/
        conf/
    apache/
        bin/
        conf/
db/
    tables/
    procs/
    triggers/

Note that right now, I don't intend to migrate to maven - I'll adapt the existing ant scripts, since they work. I'd like to keep the option of moving to maven (or something like buildr, that uses the maven layout) at some point in the future though.

So:

• Does this seem like a reasonable way of laying out the repository? Is there anything that will trip me up further down the line?
• Is this going to be obvious to people new to the app?
• Would this be compatible with maven, should I decide to use it? (I know that theoretically, you can make maven work with any layout, but I believe they recommend a standard for a reason.)
• Are IDEs going to have any problems with this? (Depending on which computer I'm on, I use intellij or eclipse. Other people on my team - who helpfully don't have opinions on this - use netbeans.)

Answer 1

• Does this seem like a reasonable way of laying out the repository? Is there anything that will trip me up further down the line?

Well, Maven captures industry best practices, including the layout, so this seems a very good choice even if you're not using Maven right now. Actually, this is the recommended migration strategy when moving from another technology to Maven: first, move to Maven layout and update the existing build scripts and then, introduce Maven. In your case, if all projects have the same lifecycle (if they are all released together), I don't have any particular remarks except maybe about the infra project that may not be managed this way with Maven but, nothing blocking right now.

• Is this going to be obvious to people new to the app?

I find it pretty clear and, honestly, if some people have a problem with it and if they can't adapt, maybe it's them that need to be fixed :)

• Would this be compatible with maven, should I decide to use it? (I know that theoretically, you can make maven work with any layout, but I believe they recommend a standard for a reason.)

It seems almost entirely compatible with Maven (except the infra part as I said but this is really not an issue). And yes, it's obviously simpler if you don't have to modify Maven's configuration and use the default conventions. Note that you could setup a Maven build in parallel of the Ant build to move seamlessly.

• Are IDEs going to have any problems with this? (Depending on which computer I'm on, I use intellij or eclipse. Other people on my team - who helpfully don't have opinions on this - use netbeans.)

It's been a long time since I didn't import an Ant project into one of these IDE but I think that they should all be able to deal with this layout (100% sure when using Maven). The best way to answer this question would be to do some testing of course :)

Answer 2

The only issue I would have is that I expect src directories to directly have source code inside, rather than how the above layout is. However I think it is a way of thinking that I could overcome quite quickly, especially within Eclipse.

Answer 3

Why are the target directories in the repository? I am a fan of not checking in build results, as they can be reproduced easily. If they can't be reproduced easily, then that is the issue that should be solved instead of checking in binaries.

Other than that I don't see any issues with this layout. Except for the tomcat directory it is the standard maven layout.