You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #451 we upgraded outright to Java 11 for master / Feast v0.5+. Subsequently in #473 we restored support for v0.3 and v0.4 maintenance branches to be tested on CI with Java 8 (thanks!). I believe that has been broken by later updates to CI scripts, I'll consider that part of this issue.
The upgrade could pose problems for Feast's Beam-based Ingestion component. Beam itself does not build with Java 11 yet, and the scope of that issue is only the DirectRunner. Other runners could lag further behind, as for example Spark does not build or run on Java 11 until its version 3.0, which is in preview. Thus I presume Beam's SparkRunner will not build with Java 11 until a GM Spark release can.
Feast does not support any runners other than GC Dataflow (and DirectRunner), so there may be no immediate issue if these are working so far. But, supporting additional runners—if anticipated (#362)—could be blocked if Ingestion does not remain Java 8-compatible.
I wanted to raise the question of whether we should (cross?) build Ingestion with Java 8 to ensure it remains compatible for awhile longer.
The bug report that follows applies to current status quo, regardless of the question above.
Expected Behavior
Feast master gives a helpful error about Java requirement if a developer attempts to build with an older version than is supported.
The unhelpful error from Maven would be improved by reverting 190e605, resulting in output like
[WARNING] Rule 1: org.apache.maven.plugins.enforcer.RequireJavaVersion failed with message:
Detected JDK Version: 1.8.0-242 is not in the allowed range [11.0,).
[ERROR] Some Enforcer rules have failed. Look above for specific messages explaining why the rule failed.
For the CI environment problem, restore compatibility of the test scripts with maven:3.6-jdk-8 Docker image. Prow always builds using master versions of scripts & config, I think? Ideally then, ensure a build is run on the maintenance branches when Prow scripts are changed, for as long as those Feast versions are supported.
For the Java 8 matter, a quick test seems to tell me that maven-compiler-plugin can compile select modules in a Reactor build with <release>8</release> while the others compile with 11. So I'm suggesting that it could be straightforward to only build Ingestion for 8, instead of cross-building for two versions and having a more complicated CI matrix. Note then that datatypes-java ought to also build with 8 to be safe.
In #451 we upgraded outright to Java 11 for master / Feast v0.5+. Subsequently in #473 we restored support for v0.3 and v0.4 maintenance branches to be tested on CI with Java 8 (thanks!). I believe that has been broken by later updates to CI scripts, I'll consider that part of this issue.
The upgrade could pose problems for Feast's Beam-based Ingestion component. Beam itself does not build with Java 11 yet, and the scope of that issue is only the DirectRunner. Other runners could lag further behind, as for example Spark does not build or run on Java 11 until its version 3.0, which is in preview. Thus I presume Beam's SparkRunner will not build with Java 11 until a GM Spark release can.
Feast does not support any runners other than GC Dataflow (and DirectRunner), so there may be no immediate issue if these are working so far. But, supporting additional runners—if anticipated (#362)—could be blocked if Ingestion does not remain Java 8-compatible.
I wanted to raise the question of whether we should (cross?) build Ingestion with Java 8 to ensure it remains compatible for awhile longer.
The bug report that follows applies to current status quo, regardless of the question above.
Expected Behavior
Current Behavior
This stems from:
https://github.com/gojek/feast/blob/7633912cd8209cece2a21ebe344600342ef1ff9b/pom.xml#L408
because the flag was added to
javacin Java 9. Maven Enforcer will catch this, proposed below.For the second problem, CI fails with:
Steps to reproduce
Possible Solution
The unhelpful error from Maven would be improved by reverting 190e605, resulting in output like
For the CI environment problem, restore compatibility of the test scripts with
maven:3.6-jdk-8Docker image. Prow always builds using master versions of scripts & config, I think? Ideally then, ensure a build is run on the maintenance branches when Prow scripts are changed, for as long as those Feast versions are supported.For the Java 8 matter, a quick test seems to tell me that maven-compiler-plugin can compile select modules in a Reactor build with
<release>8</release>while the others compile with 11. So I'm suggesting that it could be straightforward to only build Ingestion for 8, instead of cross-building for two versions and having a more complicated CI matrix. Note then thatdatatypes-javaought to also build with 8 to be safe.