Don't mean to derail the discussion, but I am wondering if sparse checkout is the last/biggest problem you have to solve to use maven for your "one biiiig ass trunk".
We are using maven for a monorepo (maybe not as "biiiig ass" as google's but pretty big nonetheless) for few years now and lack of sparse checkout was never a big problem for us. Disk space and even network are relatively cheap these days, after all. We did have to implement what we call "partial build", where we don't build the whole tree, but a subset of modules selected by the user, with the required dependencies coming as prebuilt artifacts from a repository. This is conceptually what --projects and -SNAPSHOTs claim do, only hardened to scale for large number of modules and developers. -- Regards, Igor On Tue, Jan 24, 2017, at 12:05 AM, Paul Hammant wrote: > OK, so I'm a documenter of Google's Monorepo (one biiiig ass trunk) and > it's usage of shell scripts to subset the checkout for speedy > development: > > http://paulhammant.com/2014/01/06/googlers-subset-their-trunk/ > https://trunkbaseddevelopment.com/monorepos/ > > For Maven to be used with a scripted use of Subversion or Git's > sparse-checkout (or Perforce's client spec), it'd been to be more like > Bazel/Blaze or Buck, in that sub-modules are *not* forward declared, they > are discovered/calculated/inferred somehow. > > In pom.xml instead of - > > <modules> > <module>one</module> > <module>two</module> > </modules> > > We'd need - > > <modules> > <search>recursively</search> > </modules> > > Or - > > <modules> > <defined-in>.full-module-list.txt</defined-in> > <!-- made by > find . -name "pom.xml" | sed 's/\/pom.xml//' > > .full-module-list.txt > after the sparse-checkout modification of working copy --> > </modules> > > Thoughts? > > Any questions? > > - Paul H > > PS - I'm a solid Maven user since 2003. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
