Migrating to maven from an unusual svn directory structure?_问答_开发者

Contrary to a 'normal' svn directory structure I'm using the following structure:

trunk/
  project1/
  project2/
  project3/
  ...
branches/
  project1-branch/
    project1/
    project2/
    ...
  project2-branch/
    project1/
    project2/
    ...
tags/
  project1/
    V1
    V2
    ...

As you see I don't have separate triples (trunk/branches/tags) for each project.

For development I do a checkout of trunk (sometimes a sparse checkout) containing all the projects I need (there are dependencies between the projects and some projects are simply libraries).

The benefits that I see in this are:

Update and checkin is easy, because I have a common root directory (trunk) of all projects. One simple svn update or svn commit does it all.
Creation of a tag or branch is simple, because it's only the trunk that I have to svn copy for this. (Br开发者_开发知识库anches and tags actually contain more projects than needed, but a svn copy is cheap and I still can do sparse checkouts on a branch or tag if needed.)
Moving of resources from one project to another is easy, because they all live in the same repository.
Global refactoring (for example changing the package of a commonly used class) is easy when I'm working on a full checkout of trunk, because I can be sure I don't miss a project.
Merging is easy, because I can always merge the whole branch at once even if there was a refactoring move from one project to another.

I intend to migrate to maven and split all the projects from trunk to maven projects. I'd like to benefit from the maven dependency management and from the available plugins (right now I'm using huge custom ant files).

Now my questions are:

Do I have to change the svn directory structure to give every project its own triple (trunk/branches/tags)? I guess the answer is 'yes'.
If I change the structure, which of the benefits mentioned above do I loose (I mean what will be more complicated doing it with maven)?
What are the equivalent ways to do it with maven?

There is no such thing, a "normal" svn directory structure. There are different approaches as discussed in the section called "Planning Your Repository Organization" of the Version Control with Subversion book (even the /trunk, /tags, /branches names are just conventions and there's no difference between a tag and a branch, except in your perception of them).

Do I have to change the svn directory structure to give every project its own triple (trunk/branches/tags)? I guess the answer is 'yes'.

No, you don't have to. See for example the Apache ServiceMix Source Tree: it's a multi modules maven project but the modules are under one trunk. On the other hand, XWiki which is not a single product but an ecosystem of products and projects as detailed in its Source Repository page, has many trunk/branches/tags. You can browse its repository here to get an idea of the layout.

But choosing one approach or the another is not just a matter of taste, it actually depends on your release cycle (more on mvn release later). If the components from your project share the same version (a la ServiceMix), I'd use only one trunk. If they have an independent release cycle (a la XWiki), I'd use a multiple "trunk/tags/branches" structure like the one described in this thread:

myrepo
  + .links (2)
    + trunks
      + pom.xml
  + parent-pom (1)
    + trunk
      + pom.xml
  + project-A
    + trunk
      + pom.xml
  + project-B
    + trunk
      + pom.xml 
1) The parent POM of the project has an own release cycle. Every component's POM will use it as parent (referenced simply with groupId and artifactId, no relativePath). For a release you'll have to release the parent POM first.

2) This is a construction to enable easy check outs of a specific branch of the project i.e. normally the trunk. A subversion user checks out myrepo/.links/trunk to get the head revision of all sources. The trick is, that that directory contains external links (i.e. with the svn:externals property) to the trunks of all other modules of this project (parent-pom, project-A, project-B). The pom.xml in this directory is never released, it contains simply a modules section for the three modules to enable a multi module build. With this construct you're able to setup easily branches e.g.:
myrepo
  + .links
    + branch-2.x
      + pom.xml

I've used this setup many times, it works quite well.

If I change the structure, which of the benefits mentioned above do I loose (I mean what will be more complicated doing it with maven)?

Let me answer each point one by one.

Update and checkin are easy thanks to svn externals. One simple svn update or svn commit does it all.
Creation of a tag or branch is simple because the maven release plugin will handle this for you (and tags and branches will be cleaner).
Moving of resources from one project to another doesn't look more complicated.
Global refactoring (for example changing the package of a commonly used class) is easy because you can still work on a full checkout of trunk.
Merging may be less easy. But do you really move classes from one project to another that frequently?

What are the equivalent ways to do it with maven?

Use the maven release plugin and one of the suggested layout with svn externals if required.

If you want to use Maven only for the dependency management and you think your project structure is already good enough/works well for you, here's a helpful hint: Forget Maven.

Maven is a lot more than just a dependency management tool, it calls itself "software project management and comprehension tool" which obviously covers dependencies but also a lot of other bases too. Since you only want to have dependency management, you should at least take a look at a tool such as Ant Ivy which exists solely for the purpose of managing dependencies.

The real benefit of Ivy is that you can tackle the dependency management a lot better and more fine grained than with Maven while keeping your existing project structures, build scripts and just about anything you've already built on top of it. Ivy doesn't reinforce any project structure or configuration patterns, it allows you to define what you want to get from the dependency management tool and then add it to your project instead of forcing your project to become structurally something stated by some people in ivory tower.

To further help you decide, here's comparisons between each other by both parties: