Stephen - I think think Robert's <module>def:.full-module-list.txt</module> is compatible hacking that is POM 4 friendly (and 3 for that matter) until you revisit in 5.
I'd be horrified to write more XML than I already write in Maven. I'm able to face Gradle advocates re a particular enterprise app and without feeling I'm lying to myself say "what you're showing me is more of less the same as Maven all things considered". Well if failsafe and tomcat and surefile and coverage aren't in the same solution, that is. With the profile fu, just to get Maven to follow the lead git-sparse-checkout could give for such things, I could not face anyone and say that's what you should do. - Paul On Tue, Jan 24, 2017 at 8:13 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > Yep I hear you. > > We cannot change the 4.0.0 schema > > And changing to a new modelVersion requires ensuring that we can evolve > without breaking consumers of the older model. > > Basically we have one chance to make a "breaking" change to something that > allows us to evolve going forward > > So what I provided was the 4.0.0 modelVersion solution... it's ugly but > does not require pre-processing or generation of the pom > > On Tue 24 Jan 2017 at 12:53, Paul Hammant <p...@hammant.org> wrote: > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Sent from my phone >
