Thanks for digging that up. I agree with your analysis of our public
documentation, though we still need a transition path. Officially, our
classpath is not covered by compatibility, though we know that in reality,
classpath changes are quite impactful to users.
While we were having a related disc
1.0.4:
"Prints the class path needed to get the Hadoop jar and the required
libraries.”
2.8.0 and 3.0.0:
"Prints the class path needed to get the Hadoop jar and the required
libraries. If called without arguments, then prints the classpath set up by the
command scripts, whic
I agreed with Andrew too. Users have relied for years on `hadoop classpath`
for their script to launch jobs or other tools, perhaps no the best idea to
change the behavior without providing a proper deprecation path.
thanks!
esteban.
--
Cloudera, Inc.
On Mon, Apr 3, 2017 at 10:26 AM, Andrew Wan
What's the current contract for `hadoop classpath`? Would it be safer to
introduce `hadoop userclasspath` or similar for this behavior?
I'm betting that changing `hadoop classpath` will lead to some breakages,
so I'd prefer to make this new behavior opt-in.
Best,
Andrew
On Mon, Apr 3, 2017 at 9:
This morning I had a bit of a shower thought:
With the new shaded hadoop client in 3.0, is there any reason the
default classpath should remain the full blown jar list? e.g., shouldn’t
‘hadoop classpath’ just return configuration, user supplied bits (e.g.,
HADOOP_USER_CLASSPAT
