Versus profiles, I would rather have pom.xml exhaustively renamed to pom.xml.template in SCM, and a Python script to generate <modules/> as we have it today (pom.xml marked as .gitignore) before invoking 'maven install'
- Paul On Tue, Jan 24, 2017 at 7:31 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > It's an interesting idea for model version 5.0.0 to consider. > > At present, I would handle it by using profiles with activation to pull in > the modules: > > if your activation in the root is based on the presence of the module's > pom.xml then it will only add the module if you checked it out: (approx > structure and I do not have the XSD to hand) > > <profile> > <id>module-foo</id> > <activation> > <file>module-foo/pom.xml</file> > </activation> > <modules> > <module>module-foo</module> > </modules> > </profile> > <profile> > <id>module-bar</id> > <activation> > <file>module-bar/pom.xml</file> > </activation> > <modules> > <module>module-bar</module> > </modules> > </profile> > > Yes that becomes an ugly pom, but it will do what you want when run from > the root and I have used it before > > HTH > > On 24 January 2017 at 11:14, Paul Hammant <p...@hammant.org> wrote: > > > i thought about that too, except that in a monorepo situation, I don't > want > > the don't want the changed pom to get pushed back in a commit, and I > don't > > want one of the those changelists in my IDE labeled "do not commit" to > > facilitate that. > > > > Rationale: Just because I've subset my checkout/clone doesn't mean that > all > > users of the same repo want to. > > > > It was implied, but I'll call it out: .full-module-list.txt is in > > .gitignore (etc), and that it's easily regenerate per the 'find' command. > > > > Regards, > > > > - Paul > > > > On Tue, Jan 24, 2017 at 12:50 AM, Aldrin Leal <ald...@leal.eng.br> > wrote: > > > > > Actually, I always wondered if it was interesting to have a tool to > allow > > > the modification of POM files from Command Line. Like setting a > property, > > > adding a dependency and/or, as you exposed, changing modules. > > > > > > -- > > > -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal > > > > > > On Tue, Jan 24, 2017 at 12:05 AM, 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. > > > > > > > > > >
