calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <>
Subject Re: Maven wrapper
Date Wed, 03 Jan 2018 01:01:53 GMT
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. 


> On Jan 2, 2018, at 3:31 PM, Josh Elser <> 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 <> wrote:
>>> Even if we do include mvnw, isn't it still possible to use a compatible mvn
>>> directly?
>>> --
>>> Michael Mior
>>> 2018-01-02 15:35 GMT-05:00 Julian Hyde <>:
>>>> 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
>>>> familiar with mvn.
>>>> Julian
>>>>> On Jan 2, 2018, at 12:17 PM, Vladimir Sitnikov <
>>>>> wrote:
>>>>>> Multiple versions of Maven can be installed side-by-side (and we
>>>>> 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
>>>>> plugins, etc), so that version would likely be the default.
>>>>> Vladimir

View raw message