7

My usual practice is to have a single maven project (can be multi-module) per svn trunk like this:

trunk/ (style 1)
  /pom.xml
  /submod-1
  /submod-2

Basically, the entire trunk is treated as a single release package. I find this easier to manage. There's an aggregation/parent pom to manage all modules within this trunk.

However, i noticed some of my peers organize like this:

trunk/ (style 2)
  /project-1
    /pom.xml
  /project-2
    /pom.xml

Basically, within the single svn trunk...project-1 and project-2 needs to be managed separately. i.e. I cannot checkout the trunk and work with its contents as a single multi-module maven project -something i appreciate.

Q1: When would style 2 be a good idea, if at all?

Q2: Can someone tell/point me to best practices on how to manage maven projects with subversion?

kctang
  • 10,894
  • 8
  • 44
  • 63
  • 1
    From my own experience, style 2 is just wrong, especially when doing release, need extra configuration in maven-release-plugin in order to properly release each project separately. I am curious about other seasoned developer's opinion. – yorkw Jun 12 '12 at 03:54
  • I would like to add that if you use the maven release plugin you might have issues with style 2. Though I'm not sure how it decides the location of the tags. – tom Jun 12 '12 at 06:24
  • I have a very similar question, how to download multimodule Maven project when each module is stored on the other svn repository... – Tomasz Waszczyk Jan 23 '15 at 11:31

4 Answers4

2

I have seen instances of both.

In my opinion, it depends on how independent the projects/modules are. If they have their own release plans, then it makes sense for them to have their own trunk, branches and tags. However, if the projects/modules are always released together, it may make sense for them to be part of a single trunk.

From a maven perspective, if the modules of a multi-module project inherit their <version> from the parent, then it should follow style 1 above.

Raghuram
  • 51,854
  • 11
  • 110
  • 122
2

I pretty much agree with @Raghuram's answer, but would like to add the following:

  • If you want to release projects together with the same life cycle and the same version number, you need the Style 1, with the parent POM in the root of the trunk. This parent POM then usually includes the sub projects as modules to be built from the root.
  • Style 2 makes sense if you have a set of independent projects (e.g. utilities), where you want a single SVN location (for easier administration), but have different release cycles. In this case, you don't need a root aggregator POM that includes the single project as modules. It might still make sense to have a common parent POM for the utility projects that centralizes things like compiler settings and plugin management. The difference to Style 1 is that you would never release all of the projects together. You would release a stable version of just the parent POM and then release the single utility projects as needed.

We have used both styles with great success - the main difference really is in the way and frequency you use for releasing.

With Style 2 (and the utility project example) I don't see an issue if these projects share the same SVN tags and trunk. A developer can still decide whether he wants to check out the whole utility trunk or just a single project.

nwinkler
  • 52,665
  • 21
  • 154
  • 168
1

Just look at this question and at least its most-up answer. It actually summarizes the case and says pretty everything about it.

Community
  • 1
  • 1
Michał Kalinowski
  • 16,925
  • 5
  • 35
  • 48
0

Just think to continuos integration: This thought make first approche more flexible to use with CI servers like jinkins, bitbucket or bamboo ...

oucem
  • 59
  • 1
  • 5