hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kay Kay (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-1433) Update hbase build to match core, use ivy, publish jars to maven repo, etc.
Date Tue, 05 Jan 2010 23:17:54 GMT

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


Mime
View raw message