Re: [OpenDaylight Discuss] [Odlparent-dev] Adopting maven-3.5.x as a build requirement

2018-02-27 Thread Robert Varga
On 09/02/18 09:52, Michael Vorburger wrote:
> 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.

Solving incremental builds inherently requires solving the many-to-one +
one-to-many dependency which comes from compiling multiple YANG files
into a single SchemaContext (many-to-one) and then generating code from
that (one-to-many).

Switching the build system requires to have a good solution for all the
services we use maven for today -- which in itself is a huge topic.

Those are the first two steps that need to be designed, implemented and
demonstrated before we ever seriously contemplate switching the build
system. My estimate is that it would take a couple of man-years to
prepare for integration -- hence while it is an interesting topic to me,
I feel my cycles are better used elsewhere.

As a side-note: I do not believe running a full autorelease is feasible
due to sheer disk space contraints (10s of GB) and the amount of time it
takes to run the UT suite -- which really is an important part of the
exercise. Incremental builds in this scenario require a known-good
starting point, which is exceedingly hard to ensure and hence reference
builds around the world get executed on a clean workspace.

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss


Re: [OpenDaylight Discuss] [Odlparent-dev] Adopting maven-3.5.x as a build requirement

2018-02-09 Thread Michael Vorburger
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 
wrote:

> On Thu, Feb 8, 2018 at 4:24 PM, Robert Varga  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


Re: [OpenDaylight Discuss] [Odlparent-dev] Adopting maven-3.5.x as a build requirement

2018-02-08 Thread Thanh Ha
On Thu, Feb 8, 2018 at 4:24 PM, Robert Varga  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
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss