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 cycle, Fluorine.
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> wrote: > 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. > Thanh > > > _______________________________________________ > Discuss mailing list > Discuss@lists.opendaylight.org > https://lists.opendaylight.org/mailman/listinfo/discuss > >
_______________________________________________ Discuss mailing list Discuss@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/discuss
