views:

858

answers:

2

I have never quite understood how/why I would use Maven modules (reactor builds). We have tens of libraries that we share (as dependencies) among our products, and between libraries as well. If we were to switch to making them maven modules, how would we set it up, both in svn and in our working copies? Do Maven Modules really need to be subfolders? Do they need to be subfolders in the svn repo too? Assuming you just need subfolders in the working copy, I suppose svn:externals would work to make, say, a "util" library be a module of multiple projects at the same time. But I've read many bad things about using svn:externals because there is nothing to stop you from modifying the code in the external, but its not tracked.

Any suggestions? Am I missing the boat on modules?

+2  A: 

No ... a modular project should only be used when the child project is integrated into the parent to create a larger artifact, so an example might be an Enterprise project, where your modules contain the EJB (server and client), the WAR, and then those are combined into an EAR file. This modularity is only for convenience and can be skipped if preferred.

In the case of reusable libraries, make them independent projects and deploy them to a shared repository. Then they must be referenced as dependencies in the project using them.

Steve Moyer
A: 

I guess that's a problem with subversion. Which forces you to create a folder structure for branching. Other version control systems allow branching without visibility in the folder structure, where maven modules can be created more easily.

I work with a product of more than 250 modules, and they reside in "logical" maven modules that only signify an area of functioning. e.g. "CoreService", "Utilities" and "Applications". We are very happy with using maven modules for this, since we can make sure that all CoreServices use a certain version of a certain dependency and that all applications get a certain aspectJ library woven into them.

For your solution though:

There is a feature in subversion for a module to find its parent called relativePath which is a tag in the parent tag. The only reason to put sub-projects in its parent's folder is so that they can be put in the reactor when building the parent. The child projects can still be built (and installed) individually.

There's also enhanced support for svn:externals in subersion 1.5 which allows relative URL:s, which should also come in handy in this case.

-Good luck and report back here if you find a solution!

Hugo