How'd you fix the above "dynamic linking" issue.
I have not. That is tricky because it pulls the latest snapshot across three different projects ( core . hdfs, mapreduce ) . Also - one of the hdfs snapshots (0.21 ) seemed to pull (0.22) from core. We also need to have some sort of conflict resolver specific to core / hdfs / mapreduce to prevent similar conflicts ( as opposed to the default one ).
This specific dll conflict seems to be an artifact of
HADOOP-6435 checked in recently and corresponding mismatch in other projects in picking up the same.
For a release - this would work perfect to avoid the conflicts of different versions. During development though - this would be a headache though during such major API changes. But - may be we can maintain a separate repository during development and flip the order of ivy resolvers for ( core / hdfs/ mapreduce ).
I get that for core tests at least after I changed your patch so it pulled hadoop 0.21 jars rather than hadoop 0.22 jars
Yup. I changed it to see if it avoids the dll linkage issue, but if 0.21 is what we want - we also want to add a custom ivy conflict resolvers to allow only release versions ( and maintain major / minor version compatibility ). I will look into the same.
It seems too like there other jars we could fetch like the content of lib/jsp-2.1 and in stargate, there seems to be jackson-json?
Yes - lib/jsp-2.1 , can also brought under ivy umbrella .
For json - there is this -
<dependency org="com.sun.jersey" name="jersey-json"
If we are looking for a specific json implementation - we can change this.