+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
