It is the last big problem, yes. Sent from my iPhone
> On Jan 24, 2017, at 10:10 AM, Igor Fedorenko <i...@ifedorenko.com> wrote: > > 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: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
