[
https://issues.apache.org/jira/browse/HBASE-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796906#action_12796906
]
Kay Kay commented on HBASE-1433:
--------------------------------
{quote}
I agree with Ryan. Why should I have to bother with setting up some kind of ivy
proxy (locally?) ? The first thing I do with Hadoop 0.21 is build to pull all
the dependencies into build/ivy/.... and then copy them by hand into a lib/
directory so I can put them on the Eclipse build path in a clean manner. Any
dependency changes, I have to fix them by hand. Before, SVN add/rm would handle
that for me - the committer would deal with the dependency change. I'm not
looking forward to needing to do the same thing for HBase.
My interest here is not to discourage this if people are generally in favor,
but, personally, I prefer ant. I like make. I have a good relationship with
Eclipse but otherwise IDEs get in the way. Etc. I see no personal benefit for
using ivy or maven, just an (unnecessary, IMO) learning curve, additional work
if I need to fix something to get it to work for my changes, and a truckload of
external dependencies.
{quote}
I find this thread interesting given that every other project in the eco-system
- hadoop-core / mapreduce / hdfs / mahout ( uses maven) / zookeeper (3.3.0+) go
with a dependency manager in one form or the other. It does not conflict with
Eclipse in any way since instead of lib/** - people will be required to add
build/ivy/common/** to the classpath . SVN add/rm handling dependency
management is definitely possible, but say in the case of lucene - there are at
least 6 different jars / contribs that are available and if we want to flip
between versions- adding and removing versions from source control is not fun
at all. And with ivy - there is no need to install any piece of software other
than ant itself. Version controlling snapshots of projects will make it hard
to keep up with their updates as and when they become available and goes
against the very objective of continuous build process. With this patch -
people would be modifying ivy.xml / libraries.properties at max , without
worrying about anything else and I find that way comfortable , compared to
downloading yet another installation and version controlling them (and deleting
old versions), not to mention deciding dependency management winners.
> Update hbase build to match core, use ivy, publish jars to maven repo, etc.
> ---------------------------------------------------------------------------
>
> Key: HBASE-1433
> URL: https://issues.apache.org/jira/browse/HBASE-1433
> Project: Hadoop HBase
> Issue Type: Task
> Affects Versions: 0.20.2
> Reporter: stack
> Fix For: 0.21.0
>
> Attachments: HBASE-1433.patch, HBASE-1433.patch, HBASE-1433.patch,
> HBASE-1433.patch
>
>
> We are almost close, except for the republication of artifacts to mapreduce
> snapshot repository from branch-0.21 (after applying the appropriate patch).
> It would be great to have this out for 0.21 .
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
