@Todd - Where were you a few weeks ago?
Chillin' over on the HADOOP jira We're gearing up for release of our distribution that includes Hadoop 0.20.0, so just started watching this one more carefully.
The jars are upstream in Hadoop core. I did not look into this closely but the talk about 'Sealing exceptions' above led me to believe I should not try this.
Sorry, what I meant here is that the hive tarball would include lib/hive-0.4.0.jar, lib/jetty-shims/hive-jetty-shim-v6.jar and lib/jetty-shims/hive-jetty-shim-v5.jar
In those jars we'd have two different implementations of the shim. The hive wrapper script would then do something like:
if [[ $HADOOP_JAR =~ 0.1 ]]; then
To generate the shim jars at compile time, we'd compile two different JettyShim.java files - one against the v5 API, and one against the v6 API.
As for eclipse properly completing/warning for the right versions for the right files, I haven't the foggiest idea. But I am pretty sure it's not going to warn if your reflective calls are broken either
My only concern is will the ant process cooperate?
I don't see why not - my example build here is just to show how it works in a self contained way. The stuff inside v1-classes and v2-classes in the example are the equivalent of the two jetty jar versions - we don't have to compile them. The only code that has to compile is DynamicProxy.java which is completely normal code.
If you/we can tackle the ant/eclipse issues I would be happy to use the 'Dynamic Proxy', but maybe we tackle it in a different Jira because this is a pretty big blocker and I am sure many people want to see this in the trunk.
As for committing now and not worrying, that sounds pretty reasonable, as long as there's some kind of deprecation timeline set out. (e.g "in Hive 0.5.0 we will drop support for versions of Hadoop that use Jetty v5" or whatever). As someone who isn't a major Hive contributor, I'll defer to you guys completely – I just wanted to throw the idea up on the JIRA.