I'm not proposing dropping Hadoop 1.x APIs, since most (all?) of those are still present in 2.x. Rather I'm proposing we replace Hadoop 1.x dependencies with Hadoop 2.x, no longer building releases compiled against 1.x and no longer testing against 1.x. Currently we build jars compiled against both 1.x and 2.x, but most testing (e.g., Jenkins) is only done against 1.x.
The specific problem is that the Hadoop 1.x runtime uses a Sun-specific class that causes tests to fail udner IBM's JVM, while the Hadoop 2.x runtime does not. I don't propose we make any code changes, rather just update poms to avoid this runtime problem. An alternative is to add profiles for different Hadoop versions to poms of all modules that depend on Hadoop, and to perform Jenkins testing against both profiles. The former creates a lot of duplication in the poms, making them harder to maintain. The latter adds maintenance costs to keep Jenkins running. I'm not convinced the benefit is worth the effort. Do we think folks using Hadoop 1.x will update to Avro 1.8? Doug On Fri, Aug 22, 2014 at 12:09 PM, Sean Busbey <[email protected]> wrote: > AVRO-1567 is attempting to get Avro working well with the IBM JVM and some > of our dependency on Hadoop is causing them pain. > > Specifically, there's some location where we rely on Hadoop 1 core for a > method that internally uses Sun JVM specific code. In Hadoop 2's client the > issue is fixed. > > Doug mentioned the possibility that we simply drop Hadoop 1 support for 1.8 > and rely on the presence of a fix in the Hadoop 2 version. > > What do folks think? > > Personally, I'm -0. As an alternative, I think we could change 1.8 to > default the tools artifact to Hadoop 2 without expressly dropping Hadoop 1 > support. > > Are there other compelling reasons to drop Hadoop 1 APIs? > > -- > Sean >
