I meant maven as a repository there, not as a the build system.

I haven't gone completely insane. :)  I am proposing switching from using svn 
extern to using ivy to pull the needed libraries.  This entails a lot of 
changes in the ivy configuration.  I am not proposing switching to maven, which 
would require rewriting the entire build system.

To be clear, I'm not saying maven is insane.  But rewriting the entire build 
system a few days before you want to release would be.  What I'm doing is 
foolish enough.

Alan.

On Apr 3, 2012, at 11:16 AM, David Capwell wrote:

> " and use maven to fetch Hive instead"  you mean use the maven repo or
> would this patch move off ant and to maven?
> 
> On Tue, Apr 3, 2012 at 10:50 AM, Alan Gates <[email protected]> wrote:
> 
>> I believe the artifact name is controlled by the setting of version, so
>> you could set it to whatever you wanted when you built your local copy.
>> 
>> Alan.
>> 
>> On Apr 3, 2012, at 10:42 AM, Travis Crawford wrote:
>> 
>>> Will the artifacts still have SNAPSHOT in their name? If so, it may be
>>> useful to have a unique element in their name to distinguish artifacts.
>>> 
>>> --travis
>>> 
>>> 
>>> On Tue, Apr 3, 2012 at 10:34 AM, Alan Gates <[email protected]>
>> wrote:
>>> 
>>>> No, I'm working on a patch to Hive to allow publishing changes to a
>> local
>>>> maven repo.  So you would be able to make your changes, then publish
>> them
>>>> to your maven or ivy cache, and then have HCat pick those up.
>>>> 
>>>> Alan.
>>>> 
>>>> On Apr 3, 2012, at 10:22 AM, Travis Crawford wrote:
>>>> 
>>>>> What's the workflow for making a change in Hive that's needed by
>>>> HCatalog?
>>>>> I believe the initial motivation for using an SVN extern is hive
>> changes
>>>>> will be needed faster than Hive releases updates. Will the new process
>> be
>>>>> waiting for a new Hive release with the necessary patches?
>>>>> 
>>>>> --travis
>>>>> 
>>>>> 
>>>>> 
>>>>> On Tue, Apr 3, 2012 at 9:51 AM, Alan Gates <[email protected]>
>>>> wrote:
>>>>> 
>>>>>> As you probably saw, late last week I created a tag for a rc2 for
>>>> HCatalog
>>>>>> 0.4.0.  However, I want to wait before rolling the release candidate.
>>>> Last
>>>>>> week a furor erupted on the incubator general list as to whether
>> release
>>>>>> artifacts could have _any_ binary files (including jars) in them at
>> all,
>>>>>> with some authoritative voices arguing that they could not.  You can
>> see
>>>>>> the thread here
>>>>>> 
>>>> 
>> http://mail-archives.apache.org/mod_mbox/incubator-general/201203.mbox/%3CCAOFYJNY%3DEjVHrWVvAedR3OKwCv-BkTaCbEu0ufp7OZR_gpCTiA%40mail.gmail.com%3Eifyou'vemissed
>>  it.  The outcome of that discussion is not clear to me,
>>>>>> but I think our next release candidate will have a better chance of
>>>>>> approval in the IPMC if there are no jars in it.  We can remove the
>>>>>> HCatalog jars from our release, but unfortunately the Hive code we
>> wrap
>>>>>> also contains jars.
>>>>>> 
>>>>>> The good news is that we are already working towards splitting out
>>>>>> HCatalog from Hive, both in terms of the source code and releases.  It
>>>>>> seems to me the best course is to quickly finish that work in the next
>>>> fews
>>>>>> days and incorporate that in 0.4 before rolling another release
>>>> candidate.
>>>>>> This will realize our goal of getting HCatalog to no longer extern
>> Hive
>>>>>> and make our releases easier.
>>>>>> 
>>>>>> The exact proposal is:
>>>>>> 
>>>>>> I'm working on a patch to remove hive/extern from our source tree and
>>>> use
>>>>>> maven to fetch Hive instead.  I hope to post that later today.
>>>>>> 
>>>>>> Giri is working on a patch to to remove Hive code from the HCat
>>>>>> distribution tarball.  He should post that soon.
>>>>>> 
>>>>>> Giri is also working on a patch to Bigtop to do rpms for HCatalog.  As
>>>>>> part of this we'll drop the rpm target from our build.xml.  This work
>>>>>> should also be done in the next few days.
>>>>>> 
>>>>>> Once the first two items are done, I'll roll another release
>> candidate.
>>>>>> Thoughts?
>>>>>> 
>>>>>> Alan.
>>>> 
>>>> 
>> 
>> 

Reply via email to