We already have a tool that provides a container for the whole build process. That tool is maven. I do not recall a time where someone had problems because they had the wrong version of maven installed; so this is a non-problem.
I’ve written C/C++ projects before (using autoconf, libtool, mingw etc.), and thank heavens we don’t have their problems. If we were to use a wrapper, we’d either have to get the wrapper from an external repo, or we’d have to distribute the wrapper. For the first, we’ve just shifted the version-management problem; for the second, we’d be distributing our own tool-chain, including binaries (non-source files), which is problematic for an open source project. Julian > On Jan 2, 2018, at 3:31 PM, Josh Elser <[email protected]> wrote: > > +1 to the simplicity. > > But, to Vladimir's issues (thx btw), maybe we can solve some of those > pain-points another way? I've seen some projects (notably, those with > compilation of C/C++ code) provide a Dockerfile that can create an > environment capable of building that native code. > > It seems like a lot of the things Vladimir cites could be solved by a similar > approach which would keep us on a single build tool (instead, providing a > ready-made environment to build without polluting anything else). > > I'd be OK with that approach if someone wanted to make that work. > > On 1/2/18 5:03 PM, Julian Hyde wrote: >> Yes. >> But I claim that adding mvnw to the picture makes things more complicated >> for the typical user, because there are now more options to understand. >> Julian >>> On Jan 2, 2018, at 2:00 PM, Michael Mior <[email protected]> wrote: >>> >>> Even if we do include mvnw, isn't it still possible to use a compatible mvn >>> directly? >>> >>> -- >>> Michael Mior >>> [email protected] >>> >>> 2018-01-02 15:35 GMT-05:00 Julian Hyde <[email protected]>: >>> >>>> True, but for 2 and 3 it’s not much of a hardship to type >>>> >>>> $ /usr/local/maven-x.y.z/bin/mvn -s my-settings.xml target >>>> >>>> rather than >>>> >>>> $ mvn target >>>> >>>> And for 1, I claim that typing “mvn” is less surprising to most people >>>> than typing “mvnw”. Because most people who build java code these days are >>>> familiar with mvn. >>>> >>>> Julian >>>> >>>> >>>> >>>> >>>> >>>> >>>>> On Jan 2, 2018, at 12:17 PM, Vladimir Sitnikov < >>>> [email protected]> wrote: >>>>> >>>>>> Multiple versions of Maven can be installed side-by-side (and we don't >>>>> have esoteric requirements). As such, I don't see the need for such a >>>>> change >>>>> >>>>> The reasons could include: >>>>> 1) Simplified Apache Maven installation for those who have no experience >>>>> with it >>>>> 2) Having multiple settings.xml files (e.g. if corporate rules requires >>>>> certain settings.xml that is incompatible with Apache Calcite >>>> settings.xml) >>>>> 3) Simplified management of multiple Apache Maven versions. In the same >>>>> way, corporate rules might require specific mvn version (outdated due to >>>>> plugins, etc), so that version would likely be the default. >>>>> >>>>> Vladimir >>>> >>>>
