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 <[email protected]> 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 <[email protected]> wrote:
+1 to the simplicity.
But, to Vladimir's issues (thx btw), maybe we can solve some of those
pain-points another way? I've seen some projects (notably, those with
compilation of C/C++ code) provide a Dockerfile that can create an environment
capable of building that native code.
It seems like a lot of the things Vladimir cites could be solved by a similar
approach which would keep us on a single build tool (instead, providing a
ready-made environment to build without polluting anything else).
I'd be OK with that approach if someone wanted to make that work.
On 1/2/18 5:03 PM, Julian Hyde wrote:
Yes.
But I claim that adding mvnw to the picture makes things more complicated for
the typical user, because there are now more options to understand.
Julian
On Jan 2, 2018, at 2:00 PM, Michael Mior <[email protected]> wrote:
Even if we do include mvnw, isn't it still possible to use a compatible mvn
directly?
--
Michael Mior
[email protected]
2018-01-02 15:35 GMT-05:00 Julian Hyde <[email protected]>:
True, but for 2 and 3 it’s not much of a hardship to type
$ /usr/local/maven-x.y.z/bin/mvn -s my-settings.xml target
rather than
$ mvn target
And for 1, I claim that typing “mvn” is less surprising to most people
than typing “mvnw”. Because most people who build java code these days are
familiar with mvn.
Julian
On Jan 2, 2018, at 12:17 PM, Vladimir Sitnikov <
[email protected]> wrote:
Multiple versions of Maven can be installed side-by-side (and we don't
have esoteric requirements). As such, I don't see the need for such a
change
The reasons could include:
1) Simplified Apache Maven installation for those who have no experience
with it
2) Having multiple settings.xml files (e.g. if corporate rules requires
certain settings.xml that is incompatible with Apache Calcite
settings.xml)
3) Simplified management of multiple Apache Maven versions. In the same
way, corporate rules might require specific mvn version (outdated due to
plugins, etc), so that version would likely be the default.
Vladimir
