hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Smith (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-2099) Move build to Maven
Date Sat, 20 Feb 2010 08:45:27 GMT

    [ 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.


Mime
View raw message