从ANT迁移至Maven的技术咨询：标准目录结构与SVN部署建议

1. Maven Standard Directory Structure & Implementation Tips #

First off, Maven’s standard layout is built to keep consistency across projects—this is exactly why it’ll make your builds more predictable than your old Ant setup. Here’s the core structure you’ll need to follow:

• src/main/java: Your production Java source code (all your main application logic lives here)
• src/main/resources: Non-code resources like config files, property files, or static assets for the main app
• src/main/webapp: For web projects, this holds HTML, JSPs, CSS/JS, and the WEB-INF directory
• src/test/java: Unit and integration test code (JUnit, TestNG, etc.)
• src/test/resources: Resources exclusively for testing—think test-specific configs or sample data
• target: Maven’s default output folder where all compiled classes, JARs/WARs, and build artifacts end up (add this to .svnignore immediately to keep your repo clean)
• pom.xml: The backbone of your Maven project—this file defines dependencies, build plugins, project metadata, and more

Implementation Advice: #

• Use Maven Archetypes to Kickstart: Skip manually creating folders—run mvn archetype:generate and pick the right archetype (like maven-archetype-quickstart for basic Java apps or maven-archetype-webapp for web projects). It’ll generate the full standard structure in seconds.
• Migrate Gradually: Don’t try to port all your Ant code to Maven in one go. Start with a single module or sub-app, get its build working smoothly, then repeat for others. This lets you work out dependency kinks or plugin issues without overwhelming the team.
• Replace Custom Ant Tasks with Plugins: If you had unique Ant tasks, look for Maven plugins that do the same job. For a transitional phase, you can use maven-antrun-plugin to run existing Ant scripts, but aim to switch to native Maven plugins long-term for cleaner builds.
• Enforce Consistency: Make sure everyone on the team follows the structure. Add .svnignore entries for target, IDE-specific files (like .idea or *.iml), and temporary build artifacts to keep the repo tidy.

2. SVN Directory Structure for Multiple Sub-Apps & Modules #

Since you’re starting fresh with SVN, your choice depends on how your A1-A4 sub-apps interact. Here are two solid approaches:

Option 1: Individual SVN Projects per Sub-App #

If your sub-apps are mostly independent (can be developed, tested, and released on their own terms), organize each as its own top-level SVN project with the classic trunk/branches/tags structure:

svn://your-repo/A1/
    trunk/
        module1/
        module2/
        pom.xml (parent pom for A1’s modules)
    branches/
        feature-user-auth/
        hotfix-bug-123/
    tags/
        A1-v1.0.0/
        A1-v1.1.0/
svn://your-repo/A2/
    trunk/
        ... (mirror A1’s structure)
    branches/
    tags/
...

Pros:

• Each sub-app evolves independently without risking breakage in others.
• Easier to manage permissions if different teams own different sub-apps.
• Clean, isolated release processes for individual sub-apps.

Option 2: Monorepo with Multi-Module Maven Parent #

If your sub-apps share common dependencies, need coordinated releases, or are tightly coupled, put everything under a single SVN project with a root parent pom:

svn://your-repo/your-main-project/
    trunk/
        pom.xml (root parent pom for all sub-apps)
        A1/
            module1/
            module2/
            pom.xml (A1’s sub-parent pom)
        A2/
            module3/
            pom.xml (A2’s sub-parent pom)
        ...
    branches/
        release-2.0/
        feature-cross-app-integration/
    tags/
        release-v1.0.0/
        release-v1.1.0/

Pros:

• Centralized dependency management—update a version in the root pom, and all sub-apps inherit it automatically.
• Run cross-app builds or tests with a single mvn clean install at the root.
• Coordinated releases are simpler since everything lives in one place.

Key SVN Best Practices: #

• Stick to Trunk/Branches/Tags: This is the industry standard for SVN—trunk is for active development, branches for features/hotfixes, and tags for immutable release points (never commit directly to tags!).
• Ignore Build Artifacts: As mentioned earlier, add target/ and IDE junk to .svnignore to avoid cluttering your repo with files that can be rebuilt.
• Document the Layout: Add a README.md at the root of each SVN project explaining the structure, how to build modules, and any team-specific rules. This keeps everyone on the same page.

内容的提问来源于stack exchange，提问作者Amir Timsit