[
https://issues.apache.org/jira/browse/HADOOP-11293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14207904#comment-14207904
]
Steve Loughran commented on HADOOP-11293:
-----------------------------------------
# Shell.Windows provided a feature for which there was no alternative; it's
use indicated a "desire line" that people want. Only way to really address that
is to track uses downstream (tricky) and react.
# you can't ever lock down code in an OSS project; if someone wants to they can
aways look at the code. Which would we prefer: cut-and-paste copying or direct
references. When downstream I generally prefer direct references, because it
reduces my maintenance costs
# you can keep things package scoped, but even there people can inject classes
into the package unless you seal the JARs...forcing people to build their own
JARs without the sealing.
# .NET has a better scope mode, with the {{internal}} marker able to cover
multiple libs in the same assembly, so you could make something exclusive to
the Hadoop JAR suite [[http://msdn.microsoft.com/en-us/library/7c5ka91b.aspx]]
Returning to this JIRA
* There's discussion on general about a thin client lib; something like
{{OSType}} could go in there, with Shell being kept out.
* I'd be tempted to leave things as is otherwise, upgrading shell to
public/evolving except that Shell does some stuff in static initializers that
can log @ debug, e.g.{{checkHadoopHome()}}.
* if we do add OSType, the YARN app examples should use it. If we move all and
tag it as @deprecatad then people who use it downstream will get a warning, but
it won't be enforced.
Finally, there's some intermittent discussion on common-dev about OSGi-enabling
Hadoop, so downstream apps can be more isolated from both Hadoop internals and
downstream things. But for that to work in YARN apps, we'd need to take some
internal stuff, formally make it public and then export. Identifying those bits
in use would be tricky unless we can automate it and scan over the main YARN
apps: tez, slider, flink, spark-on-yarn, Helix on yarn. And HBase, which has
had special treatment in the past.
> Factor OSType out from Shell
> ----------------------------
>
> Key: HADOOP-11293
> URL: https://issues.apache.org/jira/browse/HADOOP-11293
> Project: Hadoop Common
> Issue Type: Improvement
> Components: util
> Reporter: Yongjun Zhang
> Assignee: Yongjun Zhang
> Attachments: HADOOP-11293.001.patch
>
>
> Currently the code that detects the OS type is located in Shell.java. Code
> that need to check OS type refers to Shell, even if no other stuff of Shell
> is needed.
> I am proposing to refactor OSType out to its own class, so to make the
> OSType easier to access and the dependency cleaner.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
