Still wearing my newbie hat,... So, is there some way people embed the git repository information in their POMs to indicate which parts of the POM tree are part of a specific repository?
I guess what I am hoping for is that if you can define your git relationships in Maven POMs then all your tools should just 'do the right thing' (including Eclipse) and minimize errors by minimizing the amount of specific details you have to remember all the time? I have heard a few people warn me about git sub-modules. I will take care not to use them without understanding them. Cheers, Eric On Thu, Feb 21, 2013 at 11:44 PM, Stephen Connolly < [email protected]> wrote: > On Friday, 22 February 2013, Jörg Schaible wrote: > > > Thomas Broyer wrote: > > > > > On Thu, Feb 21, 2013 at 4:22 PM, Jörg Schaible > > > <[email protected] <javascript:;>>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. > > > > Oh, well, our setup has currently ~300 artifacts, most of them with > > individual versions. So I can assure you, you'll *need* such (nested) > > "builder poms", especially if you're working in a team environment. > > > > > 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. > > > > In Subversion we use external links to "wire" the individual projects of > > these artifacts to the project with the "builder poms". The nice part is > > then, that I can checkout simply one of these top level builder POMs to > > work > > e.g. on the head revision or the tip revisions of a branch. The external > > links will ensure that I get automatically any required project. > > > > For Git you're telling me here that I would have to handle all those Git > > repositories individually. > > > In *theory* you use git sub modules for this... But that can be more of a > pain, or at least give people false ideas about how things work. Much like > how if you peg the revision of your svn:external in such a builds pom > directory would get you in to trouble. > > I tend to stear clear of git submodules as the feel half baked to me, but > YMMV > > > > - Jörg > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected]<javascript:;> > > For additional commands, e-mail: [email protected] > <javascript:;> > > > > >
