[
https://issues.apache.org/jira/browse/HBASE-4336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253502#comment-13253502
]
Jesse Yates commented on HBASE-4336:
------------------------------------
Working with Matt Corgan a bit on getting a version compiling across machines
ran into a maven issue (see links below) where the project will build fine if
doing a 'mvn package', but 'mvn compile' will break if you have two modules
wherein one creates a test-jar and the other depends on that jar, even with a
test scope.
As maven stands now, we can only have one module that has all the test code (or
at least all the code for that module), which is a huge pain as a large amount
of code uses the minicluster.
An alternative design around this issue would be to have an hbase-test module
that has all the multi-module/mini-cluster tests, and then each of the modules
just has its own unit tests (I proposed something similar a couple months ago,
but not for this reason).
The other alternative is to actually fix maven. One of maven jiras is marked
resolved, but doesn't work on maven 3.0.x. The other has been sitting in limbo
for a couple years. I'll try to get the maven issue resolved, but that means we
will need to require people to build with the tip of maven (when the change
gets released).
The TL;DR is that until MNG-2045 gets resolved for mvn 3.0.x, it probably makes
sense to just go with with Stack's suggestion of hbase (parent), hbase-core and
hbase-assemble for the moment and work in parallel on resolving the maven jira.
Thoughts?
Maven Jira issues:
- jira.codehaus.org/browse/MNG-2045
- http://jira.codehaus.org/browse/MNG-3559)
> 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
