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