Robert, thanks for raising this; my view is +3 that we should switch to
Maven 3.5.2 (not 3.5.0) ASAP, at the beginning of the next development
I think the risk is minimal, and the only "problem" is a (minor..)
inconvenience to developers, and possibly someone's in-house downstream
build system, to have to upgrade their local Maven.
On Fri, Feb 9, 2018 at 12:21 AM, Thanh Ha <thanh...@linuxfoundation.org>
> On Thu, Feb 8, 2018 at 4:24 PM, Robert Varga <n...@hq.sk> wrote:
>> maven-3.5 is being shipped in Fedora 27 and will ship in Ubuntu 18.04
>> LTS. I have not done any research beyond that, but as Michael recently
>> noted, managing these sorts of dependencies can be done via
>> http://sdkman.io/ or similar (although their HTTPS site does not work,
>> which is worrysome).
> skdman sounds like a good find and might be worth investigating to put
> into our build images. One worry I have though is we are required to use
> OpenJDK and this page http://sdkman.io/sdks.html seems to indicate that
> it will install OracleJDK. Has anyone used this to install OpenJDK before?
Thanh, this is a confusion I can easily clarify: http://sdkman.io is
basically small script which makes it super easy to locally install,
upgrade and manage several versions of the tools listed on
http://sdkman.io/sdks.html, including a JDK and Maven (and other tools).
Personally I of course ;-) do not install Oracle's JDK with it, but have
OpenJDK on my Fedora and use sdkman only to install Maven. That will NOT
automatically also install a JDK - one explicitly choooses which of the
tools it supports one wants to install. HTH?
BTW: An alternative for us as a community could be to adopt
https://github.com/takari/maven-wrapper ... that is pretty cool, and is the
way that most Gradle-based project dances nowadays. FYI Most people NEVER
actually install Gradle, everyone git clone stuff and does ./gradlew and
that downloads and installs (the right version of!) gradle for a given
project. The maven-wrapper is the equivalent of that for Maven (it has
nothing to do with Gradle). It would be easy to add this at the root of all
ODL projects. I'm willing to help with doing that for some projects, if
there is an interest and agreement that is the way we want to go.
PS, unrelated to this thread per se, but just something I have to get off
my chest while we're on build tools: I spoke to the Maven maintainers at
FOSDEM this week-end. My impression is that Maven is history... end of the
road. For ODL longer term, we should explore moving either to
https://gradle.org or https://bazel.build, one fine day. Yeah, I fully do
realize either is a lot of work. But if anyone has an interest AND spare
cycles, please email me to discuss a cunning incremental plan... FYI this
is about much more than "our general historical use of everything
latest-and-greatest" - if we had a modern build tool with reliable
incremental build support (which is hopeless on Maven AFAIK, but supposedly
works great with Gradle and even more so Bazel), this could fundamentally
change how we could integrate... e.g. running a full autorelease on every
change would likely be feasible IMHO. Personally I do believe ODL could
eventually do integration à la "Google et al style mono repo always build
everything from head together", instead of increasingly separating projects
out of the release (like yangtools and odlparent) and then having pain on
seeing the impact of changes and paying the price when bumping. This is
fundamentally NOT a "resources issue" (like "it's too exensive for use",
because "we could never afford to amount of build VMs required"), but we
are constrained by using a legacy build tool. Just my 2 cents.
> Discuss mailing list
Discuss mailing list