hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alejandro Abdelnur <t...@cloudera.com>
Subject Re: Publishing jars for hbase compiled against hadoop 0.23.x/hadoop 2.0.x
Date Wed, 16 May 2012 23:17:58 GMT
On Wed, May 16, 2012 at 4:06 PM, Andrew Purtell <apurtell@apache.org> wrote:
>> +1 on the idea of having classifiers for the different versions we actually
>> release as proper artifacts, and should be completely reasonable to enable
>> via profiles. I'd have to double check as to _how_ people would specify
>> that classifier/version of hbase from the maven repo, but it seems entirely
>> possible (my worry here is about the collison with the -tests and -sources
>> classifiers, which are standard mvn conventions for different builds).
>> Otherwise, with maven it is very reasonable to have people hosting profiles
>> for versions that they want to support - generally, this means just another
>> settings.xml file that includes another profile that people can activate on
>> their own, when they want to build against their own version.
> This was a question I had, maybe you know. What happens if you want to
> build something like <artifact>-<version>-<classifier>-tests or
> -source? Would that work? Otherwise we'd have to add a suffix using
> property substitutions in profiles, right?

Well, we'd have to test if using <classifier> and <type>
(http://maven.apache.org/guides/mini/guide-attached-tests.html) work
as expected.

Otherwise (an it may be easier/cleaner) just use 2 different versions
for the hbase JARs, one for Hadoop1 and one for Hadoop2 (ie embedding
h1 & h2 in the version). This may be easier and less error prone for

Whatever we do should no be based on profiles as (AFAIK) the published
POMs can not be consumed activating/deactivating profiles.

And again, it would be great if all projects affected by this end up
using an identical solution.


View raw message