views:

695

answers:

2

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. (Branches 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?

A: 

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:

Esko
Thanks for your answer. I already looked at Ivy for dependency management, but I really like the maven idea of structuring all projects the same way and making the build process easy (http://maven.apache.org/what-is-maven.html).
tangens
I have to disagree with you there, using Maven project structure only makes things easier if it's the _only_ project structure in your environment. As an example how can you hammer, say, a tools library to an equal structure with a full-blown web application using Maven?
Esko
@Esko I don't get your comment
Pascal Thivent
What I mean is that Maven for you to use a single possible structure for your entire project while in the real world you most likely will have varying structures for different types of projects and as such doesn't adapt well to whatever you may already have.
Esko
I'm still not sure to get you. The OP said he wanted to use maven project structure (that is based on industry best practices), so where is the problem? And when you follow Maven's conventions, *it makes things easier*. Regarding your example, a jar and a war don't have the same structure in Maven's world too so I'm not following you.
Pascal Thivent
Best practices according to who? The problem with Maven is that it has pushed itself to present a certain way of doing things and while it's a good thing people do things similarly (such as set/get/is prefixing accessors and mutators, variablesLikethis, CONSTANTS_LIKE_THIS etc. etc.) I haven't seen a single proper authority _outside_ the Maven community saying why everyone should do things exactly the way Maven does. For me Maven is a forced standard by people in ivory tower instead of a consensus of a group proper authorities and thus Maven's POM is completely worthless to me.
Esko
If you don't want to follow Maven's conventions, don't use Maven indeed. But stop the FUD, most people are happy with them and with the benefits of conventions over configuration (and there are much more Maven users than Ivy users).
Pascal Thivent
+6  A: 

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.

Pascal Thivent
+1: Thank you very much for your comprehensive answer. I'll need some time to work through all the links and do some tests.
tangens
You're welcome. Let me know if anything isn't clear.
Pascal Thivent