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 Wed, 13 Jan 2010 23:50:55 GMT

    [ https://issues.apache.org/jira/browse/HBASE-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800020#action_12800020
] 

Paul Smith commented on HBASE-2099:
-----------------------------------

bq. Maybe its time to write the list then? The only downside I see is that if we go w/ ivy,
we are in closer alignment with the hadoop parent and adjacent projects. 

I'd like to make a little more progress (certainly getting the test cases to work) before
I make this more visible.  As I said, it's not wasted effort if it is turned down.  I'd say
that providing more substantial progress may make going to Maven more appealing.

bq. Another minor downside is the hardwired "website" that maven generates. Its hard to pull
around. Currently though, we're in alignment with parent project and we're using forrest which
is a dog.

Maven site generation is not puuurrrty, but it is functional, and the integration of all the
reports makes it functional and very useful. Apart from the report generation side of things,
the site configuration is not something I have very much experience with (in terms of configuration).
 Actually how is the HBase site generated at the moment?  I can't locate that in the build.xml/ivy
setup ?  is it external to the hbase-trunk?

bq. Paul, what you think of the circa-2006 criticisms that maven is a time sink and that it'll
make our build harder? (e.g. see commentary on spring moving to maven). Do you think newer
maven better?

2006 is ancient.  Really I would have hated to use Maven back then.  It has really come to
be very stable, and predictable now since 2.2.  2.1 went along way to convincing me it was
time to convert our corporate build system to Maven, and it has worked well.

bq. When I read the ivy site on why ivy and how it compares to maven, I buy neither. The only
arg. that makes sense for me is the one where ant remains the build driver if you go w/ ivy.
Maven does a load of nice stuff for you.

Maven does do a lot of nice things.  I think many people have had headaches _converting_ their
project to Maven, because the older setup of their build probably was 'non-standard' (that's
not saying it was bad, just not conventional).  When you drift too far from Mavens conventions,
you are starting to go against the grain and it requires more energy to do so.  As soon I
see something being 'hard' in Maven, I start to question whether trying to do it that way
is a good idea; perhaps it's simpler to just adjust the project to suit Maven (classic of
shuffling directories around to fit the common Maven cases etc).

Certainly starting off a new Maven project is a breeze, and adding new sub-modules becomes
elegant, inheriting all the definitions from the parent, making refactoring/modularizing quite
nice.

I suspect migrating an existing ant build to ivy is way simpler than going to Maven.  One
has to see the longer term benefits of Maven before it becomes compelling.



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


Mime
View raw message