You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Josh Elser <el...@apache.org> on 2018/01/02 19:34:43 UTC
Re: Maven wrapper
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
>> mmior@apache.org
>>
>> 2017-12-29 18:11 GMT-05:00 Christian Beikov <ch...@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
Posted by Sergey Nuyanzin <sn...@gmail.com>.
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 <sn...@gmail.com> 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 <jh...@apache.org> 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 <jh...@apache.org> wrote:
>> >
>> >> On Aug 28, 2018, at 8:10 AM, Josh Elser <el...@apache.org> 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
Posted by Sergey Nuyanzin <sn...@gmail.com>.
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 <jh...@apache.org> 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 <jh...@apache.org> wrote:
> >
> >> On Aug 28, 2018, at 8:10 AM, Josh Elser <el...@apache.org> 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
Posted by Julian Hyde <jh...@apache.org>.
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 <mm...@apache.org> wrote:
>
> Works for me on Ubuntu 18.04. Skimmed the doc changes as well and looks
> good to me.
> --
> Michael Mior
> mmior@apache.org
>
>
>
> Le jeu. 30 août 2018 à 19:57, Julian Hyde <jh...@apache.org> 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 <jh...@apache.org> wrote:
> > >
> > >> On Aug 28, 2018, at 8:10 AM, Josh Elser <el...@apache.org> 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
Posted by Julian Hyde <jh...@apache.org>.
Agreed. Done in latest https://github.com/julianhyde/calcite/tree/2112-mvnw <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 <mm...@apache.org> 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
> mmior@apache.org
>
>
> Le ven. 31 août 2018 à 11:05, Michael Mior <mm...@apache.org> a écrit :
>
>> Works for me on Ubuntu 18.04. Skimmed the doc changes as well and looks
>> good to me.
>> --
>> Michael Mior
>> mmior@apache.org
>>
>>
>>
>> Le jeu. 30 août 2018 à 19:57, Julian Hyde <jh...@apache.org> 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 <jh...@apache.org> wrote:
>>>>
>>>>> On Aug 28, 2018, at 8:10 AM, Josh Elser <el...@apache.org> 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
Posted by Michael Mior <mm...@apache.org>.
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
mmior@apache.org
Le ven. 31 août 2018 à 11:05, Michael Mior <mm...@apache.org> a écrit :
> Works for me on Ubuntu 18.04. Skimmed the doc changes as well and looks
> good to me.
> --
> Michael Mior
> mmior@apache.org
>
>
>
> Le jeu. 30 août 2018 à 19:57, Julian Hyde <jh...@apache.org> 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 <jh...@apache.org> wrote:
>> >
>> >> On Aug 28, 2018, at 8:10 AM, Josh Elser <el...@apache.org> 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
Posted by Michael Mior <mm...@apache.org>.
Works for me on Ubuntu 18.04. Skimmed the doc changes as well and looks
good to me.
--
Michael Mior
mmior@apache.org
Le jeu. 30 août 2018 à 19:57, Julian Hyde <jh...@apache.org> 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 <jh...@apache.org> wrote:
> >
> >> On Aug 28, 2018, at 8:10 AM, Josh Elser <el...@apache.org> 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
Posted by Julian Hyde <jh...@apache.org>.
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 <jh...@apache.org> wrote:
>
>> On Aug 28, 2018, at 8:10 AM, Josh Elser <el...@apache.org> 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
Posted by Julian Hyde <jh...@apache.org>.
> On Aug 28, 2018, at 8:10 AM, Josh Elser <el...@apache.org> 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
Posted by Josh Elser <el...@apache.org>.
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 <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 <jh...@apache.org> 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 <el...@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 <mm...@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 <jh...@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
>>>>>>
>>>>>>
>>
>
>
Re: Maven wrapper
Posted by Vladimir Sitnikov <si...@gmail.com>.
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
Posted by Michael Mior <mm...@apache.org>.
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
mmior@apache.org
Le lun. 27 août 2018 à 21:41, Julian Hyde <jh...@apache.org> 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 <jh...@apache.org> 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 <el...@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 <mm...@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 <jh...@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
> >>>>>
> >>>>>
> >
>
>
Re: Maven wrapper
Posted by Julian Hyde <jh...@apache.org>.
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 <jh...@apache.org> 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 <el...@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 <mm...@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 <jh...@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
>>>>>
>>>>>
>
Re: Maven wrapper
Posted by Julian Hyde <jh...@apache.org>.
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 <el...@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 <mm...@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 <jh...@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
>>>>
>>>>
Re: Maven wrapper
Posted by Josh Elser <el...@apache.org>.
+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 <mm...@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 <jh...@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
>>>
>>>
>
Re: Maven wrapper
Posted by Julian Hyde <jh...@apache.org>.
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 <mm...@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 <jh...@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
>>
>>
Re: Maven wrapper
Posted by Michael Mior <mm...@uwaterloo.ca>.
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 <jh...@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
>
>
Re: Maven wrapper
Posted by Julian Hyde <jh...@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 <si...@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
Posted by Vladimir Sitnikov <si...@gmail.com>.
>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