[
https://issues.apache.org/jira/browse/HBASE-4336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250828#comment-13250828
]
Jesse Yates commented on HBASE-4336:
------------------------------------
The made those decisions based discussion on this ticket about a month ago.
Essentially, we are going to have some common code between all the modules
(some people might call this core) - went with common to parallel hadoop. I
figured this refactor can handle at least pulling the easy pieces out and we
can leave the hairier 'common' utils to later (though I doubt there will be
many of those).
bq. Why do we need hbase-assemble?
from my comment above: "needed because the top level module can't depend on its
children". If we are going to build an tarball, then the packaging needs to
have the modules to build _first_ and then package them. Tried leaving it in
the parent and the parent would always build first (and fail) and then because
it was the parent, each of the children would attempt that to run that plugin
as well. Maybe someone who is better with maven can make it work, but I had
heard before that having an assembly package is necessary (its also how
accumulo does it ;)
bq. What about the profiles we currently have? Like -Phadoop 0.23. Will those
go away?
I haven't tried those yet, but then should be able to work. There is some
trickiness there with enabling/disabling things, but I think its doable.
> Convert source tree into maven modules
> --------------------------------------
>
> Key: HBASE-4336
> URL: https://issues.apache.org/jira/browse/HBASE-4336
> Project: HBase
> Issue Type: Task
> Components: build
> Reporter: Gary Helmling
> Priority: Critical
> Fix For: 0.96.0
>
>
> When we originally converted the build to maven we had a single "core" module
> defined, but later reverted this to a module-less build for the sake of
> simplicity.
> It now looks like it's time to re-address this, as we have an actual need for
> modules to:
> * provide a trimmed down "client" library that applications can make use of
> * more cleanly support building against different versions of Hadoop, in
> place of some of the reflection machinations currently required
> * incorporate the secure RPC engine that depends on some secure Hadoop classes
> I propose we start simply by refactoring into two initial modules:
> * core - common classes and utilities, and client-side code and interfaces
> * server - master and region server implementations and supporting code
> This would also lay the groundwork for incorporating the HBase security
> features that have been developed. Once the module structure is in place,
> security-related features could then be incorporated into a third module --
> "security" -- after normal review and approval. The security module could
> then depend on secure Hadoop, without modifying the dependencies of the rest
> of the HBase code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
