Hi Paul,
the problem with the proposals is that it doesn't fit the modelversion
4.0.0 (XSD)
However, what I could think of having a module with a protocol and provide
an extension which can locate the actual module locations. The extension
kicks in at startup while creating the BuildPlan.
e.g.
<modules>
<module>def:.full-module-list.txt</module>
</modules>
One question: suppose there's an issue in production, how can we get
exactly the same setup of the project to reproduce that issue? Or do you
accept that if you can't reproduce it on the master/trunk it is not an
issue anymore?
thanks,
Robert
On Tue, 24 Jan 2017 06:05:07 +0100, Paul Hammant <hamm...@apache.org>
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
