[
https://issues.apache.org/jira/browse/HBASE-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836137#action_12836137
]
Paul Smith commented on HBASE-2099:
-----------------------------------
in response to Dan's comments:
bq. any particular reason you specify versions of some plugins (e.g.
maven-source-plugin=2.1.1)?
ummm.... slackness! :) The proper (ok 'anal') Maven way is to have every
single plugin defined in a pom to have an explicit version definition. This
is so builds are completely reproducible.
By not specifying a version, during the build the most recent version is used,
so it is possible that right at the moment of producing a full ASF distribution
a plugin is updated and perhaps you get hit by a bug in that plugin.
So I would recommend we explicitly put in a version for all plugins, I think I
have a TODO in there already, but it was always my intent, even if it's just
locking in the current set of plugin versions. The ones that currently have
versions specified is probably a consequence of the fact that their example
docs have easily copy/pastable snippets containing version info... :-$
bq. maybe define the maven-compiler-plugin tweaks in the pluginManagemet
section of the pom. That way sub modules can take advantage...
I must lookup the usage of the pluginManagement section, it's not something I'm
intimate with, from experience, the sub-modules already inherit from the
top-level pom's build plugin definition (certainly seems to work like that for
our own corporate pom).
Will investigate.
bq. there is a mention of the "Aconex Snapshots" under
distributionManagement...?
Copy/paste #fail. ahem. thanks...
bq. could some of the dependencies mentioned in the core pom be optional (e.g.
hadoop-mapred, thrift). So third parties depending on hbase core don't have to
explicitly exclude stuff...
yes, that was definitely on my list to investigate, but I don't think I have a
TODO in there yet. I initially targeted by just matching the Ivy dependencies
(as much as I could, since I'm not familiar with the Ivy syntax). I would
definitely suggest we review the output of the
'mvn dependency:tree' output and go through each jar and say "oh, no, we don't
_neeeeed_ that one, lets mark that as optional'.
I definitely want to do that before the next HBase release if it's done by
Maven, we totally didn't do this when log4j switched to Maven during log4j
1.2.15 and a gazilion projects have been paying the price ever since. (I am
definitely partly to blame there for sure).
> 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: findbugs.html, findbugs.html, HBase Move Script.txt,
> HBASE-2099.13.patch, HBASE-2099.14.patch, mvn.out, test-reports.zip
>
>
> 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.
