calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <jh...@apache.org>
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. 

Julian


> On Jan 2, 2018, at 3:31 PM, Josh Elser <elserj@apache.org> 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 <mmior@uwaterloo.ca> wrote:
>>> 
>>> Even if we do include mvnw, isn't it still possible to use a compatible mvn
>>> directly?
>>> 
>>> --
>>> Michael Mior
>>> mmior@apache.org
>>> 
>>> 2018-01-02 15:35 GMT-05:00 Julian Hyde <jhyde@apache.org>:
>>> 
>>>> 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 <
>>>> sitnikov.vladimir@gmail.com> 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
>>>> 
>>>> 


Mime
View raw message