[
https://issues.apache.org/jira/browse/HBASE-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Smith updated HBASE-2099:
------------------------------
Attachment: HBASE-2099.3.full.patch
HBASE-2099.3.patch
WIP so far
* Webapps shuffled directories around, JSPC done via antrun plugin
* package-info.java generation done via antrun plugin (slight tweak to the
saveVersion.sh to provide the outputDirectory to use, this works around any
assumption about a working directory, and allows the outer Maven env to pass in
the correct value). build-helper plugin used to then compile this generated
source. Slight difference in output, because the ${project.version} is
automatically provided to the script by Maven rather than user entered (ie
'0.21.0-dev' vs. '0.22-SNAPSHOT')
Current differences between ivy- and maven-generated jars:
* conf/hbase-default.xml appears in the jar (current assumption is this is
unintended on the ivy part)
* META-INF/MANIFEST.MF is different (some extra info added by Maven, missing
the Main-Class reference, easily done in Maven, just a TODO)
* org.apache.jute and zookeeper classes added, this is due to unintended source
files being located in these artifacts binaries. Still to chase up why Maven
compiles these.
* overview.html appears in the root of the Maven jar. Should that be located
in webapps/ ?
* ivy-generated jar contains 0 byte webapps/rest/META-INF/MANIFEST.MF (as well
as one for the static tree). I'm presuming this is unintended by Ivy.
* A small binary diff on org.apache.hadoop.hbase.HTableDescriptor.class. Not
sure what that is, will need to check
* Hbase.thrift is appearing in the Maven jar. I don't think this is needed in
the jar ? Probably simpler to just move this resource into a
non-Maven-resource directory.
> Move build to Maven
> -------------------
>
> Key: HBASE-2099
> URL: https://issues.apache.org/jira/browse/HBASE-2099
> Project: Hadoop HBase
> Issue Type: Task
> Reporter: stack
> Attachments: HBASE-2099.2.full.patch, HBASE-2099.2.patch,
> HBASE-2099.3.full.patch, HBASE-2099.3.patch, HBASE-2099.patch
>
>
> This issue is for discussing pros and cons of moving hbase build to Apache
> Maven.
> Maven, if you take on its paradigm, does a lot for you. There are also a
> bunch of nice plugins that do nice reports on state of project; findbugs,
> that nice plugin where you can give out urls that will resolve to lines in
> source code (a doxygen-like thing ... I've forgotten its name). Other
> examples are a docbook plugin that would do the build inline with doc build.
> We could start up the hbase book using docbook format and the hbase book
> would ride along with versions.
> As I see it -- and its a while since I've done this stuff so things may have
> since changed -- in the way of an easy move to maven is our src/contrib
> content. Maven would have these as distinct projects pulling in their hbase
> dependency or, if you wanted to take on the maven subproject notion, then,
> hbase would be at same level in build as the contribs -- it would be a
> subproject too just built before the others.
> Anyone interested in working on this issue?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
