[jira] [Created] (CALCITE-2595) Add Maven wrapper to Avatica

[Kevin Risden (JIRA)]

Kevin Risden created CALCITE-2595:
-

 Summary: Add Maven wrapper to Avatica
 Key: CALCITE-2595
 URL: https://issues.apache.org/jira/browse/CALCITE-2595
 Project: Calcite
  Issue Type: Improvement
  Components: build
Reporter: Kevin Risden
Assignee: Julian Hyde
 Fix For: 1.18.0


A Maven wrapper is a nice idea borrowed from Gradle.
* It makes the project's build fully encapsulated. Users don't have to setup a 
version of Maven (which could potentially be different than that recommended by 
Calcite)
* It also allows Calcite to control the Maven dependency (upgrading to newer 
versions for example) making it transparent to the user. 
* Users now will use maven commands as 
{code}
./mvnw clean install
{code}
instead
{code}
mvn clean install
{code}

Presto has done the same -- https://github.com/prestodb/presto/blob/master/mvnw

It is also extremely easy to setup. See https://github.com/takari/maven-wrapper 
 . 




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Maven wrapper

[Julian Hyde]

Agreed. Done in latest https://github.com/julianhyde/calcite/tree/2112-mvnw 
.

It seems that there is consensus that the wrapper is a good thing. I’ll merge 
in the next day or two.



> On Sep 2, 2018, at 3:21 PM, Michael Mior  wrote:
> 
> One thing I didn't initially notice is that using mvnw created a directory
> .mvn in the root of the project. This should probably be added to
> .gitignore.
> 
> --
> Michael Mior
> mm...@apache.org
> 
> 
> Le ven. 31 août 2018 à 11:05, Michael Mior  a écrit :
> 
>> Works for me on Ubuntu 18.04. Skimmed the doc changes as well and looks
>> good to me.
>> --
>> Michael Mior
>> mm...@apache.org
>> 
>> 
>> 
>> Le jeu. 30 août 2018 à 19:57, Julian Hyde  a écrit :
>> 
>>> Please review https://github.com/julianhyde/calcite/tree/2112-mvnw <
>>> https://github.com/julianhyde/calcite/tree/2112-mvnw>, and give it a try
>>> in your own sandbox.
>>> 
>>> I have built on the original patch. We no longer need to include a .jar
>>> or .java. And I’ve updated the documentation to use ‘./mvnw’ rather than
>>> ‘mvn’.
>>> 
>>> Julian
>>> 
>>> 
 On Aug 28, 2018, at 10:35 AM, Julian Hyde  wrote:
 
> On Aug 28, 2018, at 8:10 AM, Josh Elser  wrote:
> 
> Is it worthwhile to share the details of that situation with the
>>> community (or are the specifics you provided all that's really relevant)?
>>> Asking to better understand if there is some legitimate criticism of what
>>> Maven lets you do, or if it's something we can make better in Calcite
>>> itself.
 
 This particular case was a consultant for my company for whom I was
>>> building a custom version of Calcite. The consultant is technical and uses
>>> git all the time, has a JVM installed on his machine (mainly for JRuby),
>>> but does not do Java development, therefore does not have maven.
 
 Since his machine is macOS it was straightforward to do “brew install
>>> maven”. (Which took about 20 minutes, because he first had to upgrade
>>> home-brew.)
 
 Clearly it was not that hard for him to install maven, but if we used
>>> mvnw we could remove even that friction.
 
> As long as we don't create a schism where some things can only be done
>>> by mvnw, I'm OK with this change.
 
 I promise that won’t happen.
 
 I believe that if you have mvn installed, mvnw will use it. Therefore
>>> most developers will continue to use the same path, regardless of whether
>>> they type “mvn” or “./mvnw”. I will continue to type “mvn”.
 
 Julan
>>> 
>>> 

Re: Maven wrapper

[Michael Mior]

One thing I didn't initially notice is that using mvnw created a directory
.mvn in the root of the project. This should probably be added to
.gitignore.

--
Michael Mior
mm...@apache.org


Le ven. 31 août 2018 à 11:05, Michael Mior  a écrit :

> Works for me on Ubuntu 18.04. Skimmed the doc changes as well and looks
> good to me.
> --
> Michael Mior
> mm...@apache.org
>
>
>
> Le jeu. 30 août 2018 à 19:57, Julian Hyde  a écrit :
>
>> Please review https://github.com/julianhyde/calcite/tree/2112-mvnw <
>> https://github.com/julianhyde/calcite/tree/2112-mvnw>, and give it a try
>> in your own sandbox.
>>
>> I have built on the original patch. We no longer need to include a .jar
>> or .java. And I’ve updated the documentation to use ‘./mvnw’ rather than
>> ‘mvn’.
>>
>> Julian
>>
>>
>> > On Aug 28, 2018, at 10:35 AM, Julian Hyde  wrote:
>> >
>> >> On Aug 28, 2018, at 8:10 AM, Josh Elser  wrote:
>> >>
>> >> Is it worthwhile to share the details of that situation with the
>> community (or are the specifics you provided all that's really relevant)?
>> Asking to better understand if there is some legitimate criticism of what
>> Maven lets you do, or if it's something we can make better in Calcite
>> itself.
>> >
>> > This particular case was a consultant for my company for whom I was
>> building a custom version of Calcite. The consultant is technical and uses
>> git all the time, has a JVM installed on his machine (mainly for JRuby),
>> but does not do Java development, therefore does not have maven.
>> >
>> > Since his machine is macOS it was straightforward to do “brew install
>> maven”. (Which took about 20 minutes, because he first had to upgrade
>> home-brew.)
>> >
>> > Clearly it was not that hard for him to install maven, but if we used
>> mvnw we could remove even that friction.
>> >
>> >> As long as we don't create a schism where some things can only be done
>> by mvnw, I'm OK with this change.
>> >
>> > I promise that won’t happen.
>> >
>> > I believe that if you have mvn installed, mvnw will use it. Therefore
>> most developers will continue to use the same path, regardless of whether
>> they type “mvn” or “./mvnw”. I will continue to type “mvn”.
>> >
>> > Julan
>>
>>

Re: Maven wrapper

[Julian Hyde]

Thanks Sergey. I contributed back to the maven-wrapper project:
https://github.com/takari/maven-wrapper/pull/89.
On Fri, Aug 31, 2018 at 8:05 AM Michael Mior  wrote:
>
> Works for me on Ubuntu 18.04. Skimmed the doc changes as well and looks
> good to me.
> --
> Michael Mior
> mm...@apache.org
>
>
>
> Le jeu. 30 août 2018 à 19:57, Julian Hyde  a écrit :
>
> > Please review https://github.com/julianhyde/calcite/tree/2112-mvnw <
> > https://github.com/julianhyde/calcite/tree/2112-mvnw>, and give it a try
> > in your own sandbox.
> >
> > I have built on the original patch. We no longer need to include a .jar or
> > .java. And I’ve updated the documentation to use ‘./mvnw’ rather than ‘mvn’.
> >
> > Julian
> >
> >
> > > On Aug 28, 2018, at 10:35 AM, Julian Hyde  wrote:
> > >
> > >> On Aug 28, 2018, at 8:10 AM, Josh Elser  wrote:
> > >>
> > >> Is it worthwhile to share the details of that situation with the
> > community (or are the specifics you provided all that's really relevant)?
> > Asking to better understand if there is some legitimate criticism of what
> > Maven lets you do, or if it's something we can make better in Calcite
> > itself.
> > >
> > > This particular case was a consultant for my company for whom I was
> > building a custom version of Calcite. The consultant is technical and uses
> > git all the time, has a JVM installed on his machine (mainly for JRuby),
> > but does not do Java development, therefore does not have maven.
> > >
> > > Since his machine is macOS it was straightforward to do “brew install
> > maven”. (Which took about 20 minutes, because he first had to upgrade
> > home-brew.)
> > >
> > > Clearly it was not that hard for him to install maven, but if we used
> > mvnw we could remove even that friction.
> > >
> > >> As long as we don't create a schism where some things can only be done
> > by mvnw, I'm OK with this change.
> > >
> > > I promise that won’t happen.
> > >
> > > I believe that if you have mvn installed, mvnw will use it. Therefore
> > most developers will continue to use the same path, regardless of whether
> > they type “mvn” or “./mvnw”. I will continue to type “mvn”.
> > >
> > > Julan
> >
> >

Re: Maven wrapper

[Michael Mior]

Works for me on Ubuntu 18.04. Skimmed the doc changes as well and looks
good to me.
--
Michael Mior
mm...@apache.org



Le jeu. 30 août 2018 à 19:57, Julian Hyde  a écrit :

> Please review https://github.com/julianhyde/calcite/tree/2112-mvnw <
> https://github.com/julianhyde/calcite/tree/2112-mvnw>, and give it a try
> in your own sandbox.
>
> I have built on the original patch. We no longer need to include a .jar or
> .java. And I’ve updated the documentation to use ‘./mvnw’ rather than ‘mvn’.
>
> Julian
>
>
> > On Aug 28, 2018, at 10:35 AM, Julian Hyde  wrote:
> >
> >> On Aug 28, 2018, at 8:10 AM, Josh Elser  wrote:
> >>
> >> Is it worthwhile to share the details of that situation with the
> community (or are the specifics you provided all that's really relevant)?
> Asking to better understand if there is some legitimate criticism of what
> Maven lets you do, or if it's something we can make better in Calcite
> itself.
> >
> > This particular case was a consultant for my company for whom I was
> building a custom version of Calcite. The consultant is technical and uses
> git all the time, has a JVM installed on his machine (mainly for JRuby),
> but does not do Java development, therefore does not have maven.
> >
> > Since his machine is macOS it was straightforward to do “brew install
> maven”. (Which took about 20 minutes, because he first had to upgrade
> home-brew.)
> >
> > Clearly it was not that hard for him to install maven, but if we used
> mvnw we could remove even that friction.
> >
> >> As long as we don't create a schism where some things can only be done
> by mvnw, I'm OK with this change.
> >
> > I promise that won’t happen.
> >
> > I believe that if you have mvn installed, mvnw will use it. Therefore
> most developers will continue to use the same path, regardless of whether
> they type “mvn” or “./mvnw”. I will continue to type “mvn”.
> >
> > Julan
>
>

Re: Maven wrapper

[Sergey Nuyanzin]

Based on [1] I added TLS12 usage by changing

powershell -Command "(New-Object
Net.WebClient).DownloadFile('%DOWNLOAD_URL%', '%WRAPPER_JAR%')"

with

powershell -Command "[Net.ServicePointManager]::SecurityProtocol =
[Net.SecurityProtocolType]::Tls12; (New-Object
Net.WebClient).DownloadFile('%DOWNLOAD_URL%', '%WRAPPER_JAR%')"

and it starts working on Windows as well

[1]
https://github.com/cretueusebiu/valet-windows/issues/78#issuecomment-369824766



On Fri, Aug 31, 2018 at 4:15 PM Sergey Nuyanzin  wrote:

> tried on
> Fedora 28 - ok
> Windows 10 - failed with
> Downloading from: "
> https://repo.maven.apache.org/maven2/io/takari/maven-wrapper/0.4.2/maven-wrapper-0.4.2.jar
> "
> Exception calling "DownloadFile" with "2" argument(s): "The request was
> aborted: Could not create SSL/TLS secure channel."
> At line:1 char:1
> + (New-Object Net.WebClient).DownloadFile('https://repo.maven.apache.or
> ...
> + ~
> + CategoryInfo  : NotSpecified: (:) [],
> MethodInvocationException
> + FullyQualifiedErrorId : WebException
>
>
> On Fri, Aug 31, 2018 at 2:57 AM Julian Hyde  wrote:
>
>> Please review https://github.com/julianhyde/calcite/tree/2112-mvnw <
>> https://github.com/julianhyde/calcite/tree/2112-mvnw>, and give it a try
>> in your own sandbox.
>>
>> I have built on the original patch. We no longer need to include a .jar
>> or .java. And I’ve updated the documentation to use ‘./mvnw’ rather than
>> ‘mvn’.
>>
>> Julian
>>
>>
>> > On Aug 28, 2018, at 10:35 AM, Julian Hyde  wrote:
>> >
>> >> On Aug 28, 2018, at 8:10 AM, Josh Elser  wrote:
>> >>
>> >> Is it worthwhile to share the details of that situation with the
>> community (or are the specifics you provided all that's really relevant)?
>> Asking to better understand if there is some legitimate criticism of what
>> Maven lets you do, or if it's something we can make better in Calcite
>> itself.
>> >
>> > This particular case was a consultant for my company for whom I was
>> building a custom version of Calcite. The consultant is technical and uses
>> git all the time, has a JVM installed on his machine (mainly for JRuby),
>> but does not do Java development, therefore does not have maven.
>> >
>> > Since his machine is macOS it was straightforward to do “brew install
>> maven”. (Which took about 20 minutes, because he first had to upgrade
>> home-brew.)
>> >
>> > Clearly it was not that hard for him to install maven, but if we used
>> mvnw we could remove even that friction.
>> >
>> >> As long as we don't create a schism where some things can only be done
>> by mvnw, I'm OK with this change.
>> >
>> > I promise that won’t happen.
>> >
>> > I believe that if you have mvn installed, mvnw will use it. Therefore
>> most developers will continue to use the same path, regardless of whether
>> they type “mvn” or “./mvnw”. I will continue to type “mvn”.
>> >
>> > Julan
>>
>>
>
> --
> Best regards,
> Sergey
>


-- 
Best regards,
Sergey

Re: Maven wrapper

[Sergey Nuyanzin]

tried on
Fedora 28 - ok
Windows 10 - failed with
Downloading from: "
https://repo.maven.apache.org/maven2/io/takari/maven-wrapper/0.4.2/maven-wrapper-0.4.2.jar
"
Exception calling "DownloadFile" with "2" argument(s): "The request was
aborted: Could not create SSL/TLS secure channel."
At line:1 char:1
+ (New-Object Net.WebClient).DownloadFile('https://repo.maven.apache.or ...
+ ~
+ CategoryInfo  : NotSpecified: (:) [],
MethodInvocationException
+ FullyQualifiedErrorId : WebException


On Fri, Aug 31, 2018 at 2:57 AM Julian Hyde  wrote:

> Please review https://github.com/julianhyde/calcite/tree/2112-mvnw <
> https://github.com/julianhyde/calcite/tree/2112-mvnw>, and give it a try
> in your own sandbox.
>
> I have built on the original patch. We no longer need to include a .jar or
> .java. And I’ve updated the documentation to use ‘./mvnw’ rather than ‘mvn’.
>
> Julian
>
>
> > On Aug 28, 2018, at 10:35 AM, Julian Hyde  wrote:
> >
> >> On Aug 28, 2018, at 8:10 AM, Josh Elser  wrote:
> >>
> >> Is it worthwhile to share the details of that situation with the
> community (or are the specifics you provided all that's really relevant)?
> Asking to better understand if there is some legitimate criticism of what
> Maven lets you do, or if it's something we can make better in Calcite
> itself.
> >
> > This particular case was a consultant for my company for whom I was
> building a custom version of Calcite. The consultant is technical and uses
> git all the time, has a JVM installed on his machine (mainly for JRuby),
> but does not do Java development, therefore does not have maven.
> >
> > Since his machine is macOS it was straightforward to do “brew install
> maven”. (Which took about 20 minutes, because he first had to upgrade
> home-brew.)
> >
> > Clearly it was not that hard for him to install maven, but if we used
> mvnw we could remove even that friction.
> >
> >> As long as we don't create a schism where some things can only be done
> by mvnw, I'm OK with this change.
> >
> > I promise that won’t happen.
> >
> > I believe that if you have mvn installed, mvnw will use it. Therefore
> most developers will continue to use the same path, regardless of whether
> they type “mvn” or “./mvnw”. I will continue to type “mvn”.
> >
> > Julan
>
>

-- 
Best regards,
Sergey

Re: Maven wrapper

[Julian Hyde]

Please review https://github.com/julianhyde/calcite/tree/2112-mvnw 
, and give it a try in 
your own sandbox.

I have built on the original patch. We no longer need to include a .jar or 
.java. And I’ve updated the documentation to use ‘./mvnw’ rather than ‘mvn’.

Julian


> On Aug 28, 2018, at 10:35 AM, Julian Hyde  wrote:
> 
>> On Aug 28, 2018, at 8:10 AM, Josh Elser  wrote:
>> 
>> Is it worthwhile to share the details of that situation with the community 
>> (or are the specifics you provided all that's really relevant)? Asking to 
>> better understand if there is some legitimate criticism of what Maven lets 
>> you do, or if it's something we can make better in Calcite itself.
> 
> This particular case was a consultant for my company for whom I was building 
> a custom version of Calcite. The consultant is technical and uses git all the 
> time, has a JVM installed on his machine (mainly for JRuby), but does not do 
> Java development, therefore does not have maven. 
> 
> Since his machine is macOS it was straightforward to do “brew install maven”. 
> (Which took about 20 minutes, because he first had to upgrade home-brew.)
> 
> Clearly it was not that hard for him to install maven, but if we used mvnw we 
> could remove even that friction.
> 
>> As long as we don't create a schism where some things can only be done by 
>> mvnw, I'm OK with this change.
> 
> I promise that won’t happen.
> 
> I believe that if you have mvn installed, mvnw will use it. Therefore most 
> developers will continue to use the same path, regardless of whether they 
> type “mvn” or “./mvnw”. I will continue to type “mvn”.
> 
> Julan

Re: Maven wrapper

[Julian Hyde]

> On Aug 28, 2018, at 8:10 AM, Josh Elser  wrote:
> 
> Is it worthwhile to share the details of that situation with the community 
> (or are the specifics you provided all that's really relevant)? Asking to 
> better understand if there is some legitimate criticism of what Maven lets 
> you do, or if it's something we can make better in Calcite itself.

This particular case was a consultant for my company for whom I was building a 
custom version of Calcite. The consultant is technical and uses git all the 
time, has a JVM installed on his machine (mainly for JRuby), but does not do 
Java development, therefore does not have maven. 

Since his machine is macOS it was straightforward to do “brew install maven”. 
(Which took about 20 minutes, because he first had to upgrade home-brew.)

Clearly it was not that hard for him to install maven, but if we used mvnw we 
could remove even that friction.

> As long as we don't create a schism where some things can only be done by 
> mvnw, I'm OK with this change.

I promise that won’t happen.

I believe that if you have mvn installed, mvnw will use it. Therefore most 
developers will continue to use the same path, regardless of whether they type 
“mvn” or “./mvnw”. I will continue to type “mvn”.

Julan

Re: Maven wrapper

[Josh Elser]

Is it worthwhile to share the details of that situation with the 
community (or are the specifics you provided all that's really 
relevant)? Asking to better understand if there is some legitimate 
criticism of what Maven lets you do, or if it's something we can make 
better in Calcite itself.


As long as we don't create a schism where some things can only be done 
by mvnw, I'm OK with this change. Hovering somewhere around a "0".


On 8/27/18 9:41 PM, Julian Hyde wrote:

Re-opening a discussion from earlier this year (and logged as 
https://issues.apache.org/jira/browse/CALCITE-2112 
).

I have changed my mind on this issue. I encountered a user today for whom 
getting a valid version of maven was a significant obstacle. I am now +1 — I 
think it would be beneficial to include mvnw and mvnw.bat in the source 
distribution, and use them in our default build instructions.

I do not think it increases complexity. Advanced users can use “mvn” if they 
choose, but the default instructions would mention only “./mvnw”.

We do not need to include maven-wrapper.jar or MavenWrapperDownloader.jar. mvnw 
and mvnw.bat work fine without them. As they make release votes more 
complicated, I think we should exclude these.

There were a mixture or -1, -0 and +1 in the original thread. Has anyone else 
changed position?

Julian



On Jan 2, 2018, at 5:01 PM, Julian Hyde  wrote:

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  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
mm...@apache.org

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 are
familiar with mvn.

Julian







On Jan 2, 2018, at 12:17 PM, Vladimir Sitnikov <

sitnikov.vladi...@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

Re: Maven wrapper

[Vladimir Sitnikov]

Just to clarify: I was always +1 re Maven wrapper.

PS. Hopefully it is a small step forward to Gradle wrapper :)
Vladimir

Re: Maven wrapper

[Michael Mior]

I was originally -0 which I will change to +0 (I could probably be
convinced to be +1). I don't see any major issue in including since it's
just two files that we can easily remove later if we choose to. If we do
this, we definitely should have the default instructions use mvnw as Julian
suggested and update CI to use it as well.

--
Michael Mior
mm...@apache.org



Le lun. 27 août 2018 à 21:41, Julian Hyde  a écrit :

> Re-opening a discussion from earlier this year (and logged as
> https://issues.apache.org/jira/browse/CALCITE-2112 <
> https://issues.apache.org/jira/browse/CALCITE-2112>).
>
> I have changed my mind on this issue. I encountered a user today for whom
> getting a valid version of maven was a significant obstacle. I am now +1 —
> I think it would be beneficial to include mvnw and mvnw.bat in the source
> distribution, and use them in our default build instructions.
>
> I do not think it increases complexity. Advanced users can use “mvn” if
> they choose, but the default instructions would mention only “./mvnw”.
>
> We do not need to include maven-wrapper.jar or MavenWrapperDownloader.jar.
> mvnw and mvnw.bat work fine without them. As they make release votes more
> complicated, I think we should exclude these.
>
> There were a mixture or -1, -0 and +1 in the original thread. Has anyone
> else changed position?
>
> Julian
>
>
> > On Jan 2, 2018, at 5:01 PM, Julian Hyde  wrote:
> >
> > 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  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
>  mm...@apache.org
> 
>  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 are
> > familiar with mvn.
> >
> > Julian
> >
> >
> >
> >
> >
> >
> >> On Jan 2, 2018, at 12:17 PM, Vladimir Sitnikov <
> > sitnikov.vladi...@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
> >
> >
> >
>
>

Re: Maven wrapper

[Julian Hyde]

Re-opening a discussion from earlier this year (and logged as 
https://issues.apache.org/jira/browse/CALCITE-2112 
).

I have changed my mind on this issue. I encountered a user today for whom 
getting a valid version of maven was a significant obstacle. I am now +1 — I 
think it would be beneficial to include mvnw and mvnw.bat in the source 
distribution, and use them in our default build instructions.

I do not think it increases complexity. Advanced users can use “mvn” if they 
choose, but the default instructions would mention only “./mvnw”.

We do not need to include maven-wrapper.jar or MavenWrapperDownloader.jar. mvnw 
and mvnw.bat work fine without them. As they make release votes more 
complicated, I think we should exclude these.

There were a mixture or -1, -0 and +1 in the original thread. Has anyone else 
changed position?

Julian


> On Jan 2, 2018, at 5:01 PM, Julian Hyde  wrote:
> 
> 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  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
 mm...@apache.org
 
 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 are
> familiar with mvn.
> 
> Julian
> 
> 
> 
> 
> 
> 
>> On Jan 2, 2018, at 12:17 PM, Vladimir Sitnikov <
> sitnikov.vladi...@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
> 
> 
> 

Re: Maven wrapper

[Julian Hyde]

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  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
>>> mm...@apache.org
>>> 
>>> 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 are
 familiar with mvn.
 
 Julian
 
 
 
 
 
 
> On Jan 2, 2018, at 12:17 PM, Vladimir Sitnikov <
 sitnikov.vladi...@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
 
 

Re: Maven wrapper

[Julian Hyde]

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
> mm...@apache.org
> 
> 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 are
>> familiar with mvn.
>> 
>> Julian
>> 
>> 
>> 
>> 
>> 
>> 
>>> On Jan 2, 2018, at 12:17 PM, Vladimir Sitnikov <
>> sitnikov.vladi...@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
>> 
>> 

Re: Maven wrapper

[Michael Mior]

Even if we do include mvnw, isn't it still possible to use a compatible mvn
directly?

--
Michael Mior
mm...@apache.org

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 are
> familiar with mvn.
>
> Julian
>
>
>
>
>
>
> > On Jan 2, 2018, at 12:17 PM, Vladimir Sitnikov <
> sitnikov.vladi...@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
>
>

Re: Maven wrapper

[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 are 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 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

Re: Maven wrapper

[Vladimir Sitnikov]

>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

Re: Maven wrapper

[Josh Elser]

Well put, all. I think I would be -1 on such a change without 
better/specific reasons as to what is broken/bad.


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.


On 12/31/17 2:27 AM, Julian Hyde wrote:

I’m -0 also. There is a cost - including a .jar in our source repo and distro 
is a code smell to some people - and I don’t see a clear benefit, when the 
industry standard is to use maven.

Julian



On Dec 30, 2017, at 8:50 PM, Michael Mior <mm...@uwaterloo.ca> wrote:

I agree with Christian. We don't require a particularly recent version of
Maven, so I don't think there's much benefit in having the wrapper.
However, I also don't think there's a major downside to including it, so
I'll come in at -0.

--
Michael Mior
mm...@apache.org

2017-12-29 18:11 GMT-05:00 Christian Beikov <christian.bei...@gmail.com>:


I didn't have the need for something like that up until now in any of the
projects I worked on. I guess if there is some feature from a very recent
Maven release that we would like to make use of, it would make sense to use
that wrapper script. Since the current minimum version that is required for
a build seems to be satisfied by the installations most users have, I don't
see a reason for doing this yet. I'd suggest we do this when a new Maven
model is released that might not be too widespread yet.


Mit freundlichen Grüßen,

*Christian Beikov*

Am 29.12.2017 um 21:42 schrieb Julian Hyde:


We have a pull request for a maven wrapper[1]. People would not need to
install maven to build Calcite, but we would include shell/cmd scripts and
a bootstrap .jar. It would allow us to use a specific version of maven (not
that this has been a problem to date). It would make our release process a
bit more complicated (we’d be shipping a binary in the .jar file) and we’d
have to change instructions in several locations.

What do you all think of the idea?

I don’t think we should change something as fundamental as our build
process unless there is a substantial majority in favor.

Julian

[1] https://issues.apache.org/jira/browse/CALCITE-2112 <
https://issues.apache.org/jira/browse/CALCITE-2112>

Re: Maven wrapper

[Julian Hyde]

I’m -0 also. There is a cost - including a .jar in our source repo and distro 
is a code smell to some people - and I don’t see a clear benefit, when the 
industry standard is to use maven.

Julian


> On Dec 30, 2017, at 8:50 PM, Michael Mior <mm...@uwaterloo.ca> wrote:
> 
> I agree with Christian. We don't require a particularly recent version of
> Maven, so I don't think there's much benefit in having the wrapper.
> However, I also don't think there's a major downside to including it, so
> I'll come in at -0.
> 
> --
> Michael Mior
> mm...@apache.org
> 
> 2017-12-29 18:11 GMT-05:00 Christian Beikov <christian.bei...@gmail.com>:
> 
>> I didn't have the need for something like that up until now in any of the
>> projects I worked on. I guess if there is some feature from a very recent
>> Maven release that we would like to make use of, it would make sense to use
>> that wrapper script. Since the current minimum version that is required for
>> a build seems to be satisfied by the installations most users have, I don't
>> see a reason for doing this yet. I'd suggest we do this when a new Maven
>> model is released that might not be too widespread yet.
>> 
>> 
>> Mit freundlichen Grüßen,
>> ----
>> *Christian Beikov*
>> 
>> Am 29.12.2017 um 21:42 schrieb Julian Hyde:
>> 
>>> We have a pull request for a maven wrapper[1]. People would not need to
>>> install maven to build Calcite, but we would include shell/cmd scripts and
>>> a bootstrap .jar. It would allow us to use a specific version of maven (not
>>> that this has been a problem to date). It would make our release process a
>>> bit more complicated (we’d be shipping a binary in the .jar file) and we’d
>>> have to change instructions in several locations.
>>> 
>>> What do you all think of the idea?
>>> 
>>> I don’t think we should change something as fundamental as our build
>>> process unless there is a substantial majority in favor.
>>> 
>>> Julian
>>> 
>>> [1] https://issues.apache.org/jira/browse/CALCITE-2112 <
>>> https://issues.apache.org/jira/browse/CALCITE-2112>
>>> 
>> 
>> 

Re: Maven wrapper

[Michael Mior]

I agree with Christian. We don't require a particularly recent version of
Maven, so I don't think there's much benefit in having the wrapper.
However, I also don't think there's a major downside to including it, so
I'll come in at -0.

--
Michael Mior
mm...@apache.org

2017-12-29 18:11 GMT-05:00 Christian Beikov <christian.bei...@gmail.com>:

> I didn't have the need for something like that up until now in any of the
> projects I worked on. I guess if there is some feature from a very recent
> Maven release that we would like to make use of, it would make sense to use
> that wrapper script. Since the current minimum version that is required for
> a build seems to be satisfied by the installations most users have, I don't
> see a reason for doing this yet. I'd suggest we do this when a new Maven
> model is released that might not be too widespread yet.
>
>
> Mit freundlichen Grüßen,
> 
> *Christian Beikov*
>
> Am 29.12.2017 um 21:42 schrieb Julian Hyde:
>
>> We have a pull request for a maven wrapper[1]. People would not need to
>> install maven to build Calcite, but we would include shell/cmd scripts and
>> a bootstrap .jar. It would allow us to use a specific version of maven (not
>> that this has been a problem to date). It would make our release process a
>> bit more complicated (we’d be shipping a binary in the .jar file) and we’d
>> have to change instructions in several locations.
>>
>> What do you all think of the idea?
>>
>> I don’t think we should change something as fundamental as our build
>> process unless there is a substantial majority in favor.
>>
>> Julian
>>
>> [1] https://issues.apache.org/jira/browse/CALCITE-2112 <
>> https://issues.apache.org/jira/browse/CALCITE-2112>
>>
>
>

Re: Maven wrapper

[Christian Beikov]

I didn't have the need for something like that up until now in any of 
the projects I worked on. I guess if there is some feature from a very 
recent Maven release that we would like to make use of, it would make 
sense to use that wrapper script. Since the current minimum version that 
is required for a build seems to be satisfied by the installations most 
users have, I don't see a reason for doing this yet. I'd suggest we do 
this when a new Maven model is released that might not be too widespread 
yet.



Mit freundlichen Grüßen,

*Christian Beikov*
Am 29.12.2017 um 21:42 schrieb Julian Hyde:

We have a pull request for a maven wrapper[1]. People would not need to install 
maven to build Calcite, but we would include shell/cmd scripts and a bootstrap 
.jar. It would allow us to use a specific version of maven (not that this has 
been a problem to date). It would make our release process a bit more 
complicated (we’d be shipping a binary in the .jar file) and we’d have to 
change instructions in several locations.

What do you all think of the idea?

I don’t think we should change something as fundamental as our build process 
unless there is a substantial majority in favor.

Julian

[1] https://issues.apache.org/jira/browse/CALCITE-2112 
<https://issues.apache.org/jira/browse/CALCITE-2112>

Maven wrapper

[Julian Hyde]

We have a pull request for a maven wrapper[1]. People would not need to install 
maven to build Calcite, but we would include shell/cmd scripts and a bootstrap 
.jar. It would allow us to use a specific version of maven (not that this has 
been a problem to date). It would make our release process a bit more 
complicated (we’d be shipping a binary in the .jar file) and we’d have to 
change instructions in several locations.

What do you all think of the idea? 

I don’t think we should change something as fundamental as our build process 
unless there is a substantial majority in favor.

Julian

[1] https://issues.apache.org/jira/browse/CALCITE-2112 
<https://issues.apache.org/jira/browse/CALCITE-2112>

[jira] [Created] (CALCITE-2112) Add Maven wrapper to Calcite

[Ratandeep Ratti (JIRA)]

Ratandeep Ratti created CALCITE-2112:


 Summary: Add Maven wrapper to Calcite
 Key: CALCITE-2112
 URL: https://issues.apache.org/jira/browse/CALCITE-2112
 Project: Calcite
  Issue Type: Improvement
  Components: build
Reporter: Ratandeep Ratti
Assignee: Julian Hyde


A Maven wrapper is a nice idea borrowed from Gradle.
* It makes the project's build fully encapsulated. Users don't have to setup a 
version of Maven (which could potentially be different than that recommended by 
Calcite)
* It also allows Calcite to control the Maven dependency (upgrading to newer 
versions for example) making it transparent to the user. 
* Users now will use maven commands as 
{code}
./mvnw clean install
{code}
instead
{code}
mvn clean install
{code}

Presto has done the same -- https://github.com/prestodb/presto/blob/master/mvnw

It is also extremely easy to setup. See https://github.com/takari/maven-wrapper 
 . 




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)