100% agree that teams not using this feature should be able to carry on unchanged. If the likes of JetBrains have to do extra code for the short-hand inside <module/> that Robert proposed, then I'm sure they'll agree with me that that is the cost of doing business. And from that they can choose to delay it too, or wait for a PR from someone who has cloned their GH repo.
Sent from my iPhone > On Jan 24, 2017, at 8:50 AM, Stephen Connolly > <stephen.alan.conno...@gmail.com> wrote: > > I don't disagree... but > > There is tooling that parses the Pom directly and has made assumptions > about the modules tag and its structure > > We would break such tooling with such a seemingly trivial change (I know of > at least 5 of my employer's customers who I would be quite upset... any my > employer is focused on a different product from Maven) > > >> On Tue 24 Jan 2017 at 13:33, Paul Hammant <p...@hammant.org> wrote: >> >> 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 >> >>> >> >> -- > Sent from my phone --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
