On Thu, Feb 21, 2013 at 4:22 PM, Jörg Schaible <joerg.schai...@scalaris.com>wrote:
> Hi Eric, > > Eric Kolotyluk wrote: > > > OK, I think I've got it. > > > > The answer depends more on what artifacts will always have the same > > version number, than how many artifacts there are. > > > > In a nutshell, one repository for the entire multi-module project is > > best, where all the artifacts keep their versions in sync with the > > parent pom. > > > > But, if you have to support artifacts with versions out of sync, then > > the out of sync versions need their own repositories. More work to > > manage, but sometimes necessary. > > What I always wonder here in combination with Git is, where do I keep my > "builder POMs" i.e. the pom that declares all the modules that includes all > these loosely coupled projects? In Subversion the location of "trunk" > defines what shares the version, but I can keep those poms in the trunk's > parent. I have nothing in Git. What do other people here? > > If you have several Git repos, it's because you have artifacts with different lifecycles, released on their own, at their own pace. Your "app" will then simply *depend* on your "lib", just like any other Maven artifact; you don't need "builder POMs" as you call them. In the event you want them anyway, then create a Git repo containing only that POM and using “git submodules” to bring the other repos in the tree. But you'll have to manage which revision of each remote repo you want to use, so there's absolutely no added value compared to simply depending on the artifacts, each built independently of the others. -- Thomas Broyer /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
