Hi all, Jörg Schaible wrote: > I can assure you, you'll *need* such (nested) "builder poms"
I agree, if you need a single build of all modules from the command line for some reason. Not everyone needs that, though. For example, if you develop in Eclipse with actively-developed projects open, M2E will already link them all as project dependencies. And/or if you have a CIS which has a proper separate job for each separately-versioned thing (i.e., one job per same-versioned multi-module build of a particular git repository), changes will be deployed to your MRM automatically, so your whole team can often get by without any combined "builder POMs". Stephen Connolly wrote: > I tend to stear clear of git submodules as the feel half baked to me I agree. My main beef with git submodules is that you cannot tie a submodule pointer to the tip of a branch, but only to specific commits. So they are always pinned, never fluid. It becomes a pain (sometimes a nightmare) keeping them all up-to-date. To use the Maven analogy: git submodules are always releases, never snapshots. Eric Kolotyluk wrote: > 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? If you use Eclipse, and/or have a CIS set up, you probably do not need builder POMs, nor any special declaration of git repository relationships. Just open whichever project(s) are relevant in Eclipse, hack on the code, and everything will stay linked. If working on the command line, you can "mvn install" changed artifacts, and then when testing downstream projects, the new version will be used. In a distributed team, as long as you have a CIS and push your changes, the CIS will build and deploy the new version, so your other team members just have to "mvn -U" to receive your updated snapshot builds. YMMV, but that has been my experience anyway. Regards, Curtis On Fri, Feb 22, 2013 at 10:21 AM, Eric Kolotyluk <eric.koloty...@gmail.com>wrote: > 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 < > stephen.alan.conno...@gmail.com> 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 > > > > <joerg.schai...@scalaris.com <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: users-unsubscr...@maven.apache.org > <javascript:;> > > > For additional commands, e-mail: users-h...@maven.apache.org > > <javascript:;> > > > > > > > > >
