[
https://issues.apache.org/jira/browse/YARN-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15876620#comment-15876620
]
Haibo Chen commented on YARN-4985:
----------------------------------
Apologies for my delayed response! I did not have answers to your questions, so
I took some time to actually try it out. Attached is my POC patch.
I managed to extract a common module that both client and server code depend
on. The number of dependencies of the new schema module is much smaller, but
still include hadoop-yarn-api (for use of ApplicationId) and
hadoop-yarn-server-applicationhistoryservice (for use of GenericObjectMapper),
as I think ValueConverters belong to schema. With this new module, the
undesirable dependency of hbase-server module on hbase-client is no longer
necessary.
I was not able to, however, redistribute tests in hbase-tests into client and
server modules. The reason is that all tests, regardless of whether it is
server or client, depend on HBaseTestingUtility which only works with
hadoop-common-2.5.1. Therefore, in that sense, I think both tests for
hbase-client and tests for hbase-server should still reside in the same module.
With this new module, we do still have the coprocessor installation issue. I am
totally speculating here. Is it possible to configure maven so that it will
combine hbase-schema and hbase-server into one jar, as a workaround?
> Refactor the coprocessor code & other definition classes into independent
> packages
> ----------------------------------------------------------------------------------
>
> Key: YARN-4985
> URL: https://issues.apache.org/jira/browse/YARN-4985
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: timelineserver
> Reporter: Vrushali C
> Assignee: Haibo Chen
> Labels: YARN-5355
> Attachments: YARN-4985-YARN-5355.prelim.patch
>
>
> As part of the coprocessor deployment, we have realized that it will be much
> cleaner to have the coprocessor code sit in a package which does not depend
> on hadoop-yarn-server classes. It only needs hbase and other util classes.
> These util classes and tag definition related classes can be refactored into
> their own independent "definition" class package so that making changes to
> coprocessor code, upgrading hbase, deploying hbase on a different hadoop
> version cluster etc all becomes operationally much easier and less error
> prone to having different library jars etc.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
