Re: Improving Kudu Build Support
I'm in favor of not spending developer time and effort to maintain compatibility with 14.04. Personally I'm still developing on Ubuntu 14.04 so I'd be happy if we can support it without much pain. On the other hand it EOLs in April 2019, so I might as well go to 18.04 now, should we decide to drop support. Maybe not many other folks are on 14.04 after all? On Mon, Aug 20, 2018 at 10:06 AM Thomas Tauber-Marshall < tmarsh...@cloudera.com> wrote: > Impala community, > > For years now, Impala has utilized tarballs built by Cloudera and uploaded > to S3 for running most of the Hadoop components in the testing minicluster. > The one exception to this is Kudu, which is instead provided by the > toolchain. > > This was never ideal - native-toolchain makes more sense for libraries > where we want to build against a fairly static version, but Kudu is under > active development and we'd like to always build against a relatively > up-to-date version. As a result, patches just bumping the version of Kudu > make up a significant portion of the commit history of native-toolchain. > > Thanks to work I'm currently doing at Cloudera, there will soon be snapshot > tarballs of Kudu getting uploaded to S3 along with the other Hadoop > components. I would like to propose that Impala switch to using those > instead of the toolchain Kudu. > > One problem here is that the new Kudu tarballs will not be getting build > for Ubuntu 14.04, only 16.04, but we still officially say we support > development on 14.04. > > One option here would be to maintain the toolchain Kudu for now and hide > downloading of the new tarballs behind a flag. We could also postpone some > of this work until 14.04 is less common. Or, given that the > bootstrap_development script already only supports 16.04, we might want to > just drop support for building on 14.04. > > Thoughts? >
java target version in FE pom?
Hey folks, I noticed that whenever I import the FE into Eclipse it ends up defaulting to Java 1.7, and then gets errors trying to run the tests: F0820 15:21:17.184092 59731 frontend.cc:109] java.lang.UnsupportedClassVersionError: org/apache/hadoop/conf/Configuration : Unsupported major.minor version 52.0 It seems this is because the pom has the following: org.apache.maven.plugins maven-compiler-plugin 3.3 1.7 1.7 Given that Hadoop is now being built for 1.8, should we change our own target and source versions accordingly? -Todd -- Todd Lipcon Software Engineer, Cloudera
Improving Kudu Build Support
Impala community, For years now, Impala has utilized tarballs built by Cloudera and uploaded to S3 for running most of the Hadoop components in the testing minicluster. The one exception to this is Kudu, which is instead provided by the toolchain. This was never ideal - native-toolchain makes more sense for libraries where we want to build against a fairly static version, but Kudu is under active development and we'd like to always build against a relatively up-to-date version. As a result, patches just bumping the version of Kudu make up a significant portion of the commit history of native-toolchain. Thanks to work I'm currently doing at Cloudera, there will soon be snapshot tarballs of Kudu getting uploaded to S3 along with the other Hadoop components. I would like to propose that Impala switch to using those instead of the toolchain Kudu. One problem here is that the new Kudu tarballs will not be getting build for Ubuntu 14.04, only 16.04, but we still officially say we support development on 14.04. One option here would be to maintain the toolchain Kudu for now and hide downloading of the new tarballs behind a flag. We could also postpone some of this work until 14.04 is less common. Or, given that the bootstrap_development script already only supports 16.04, we might want to just drop support for building on 14.04. Thoughts?
