On Fri, Mar 22, 2013 at 4:49 AM, Jimmy Xiang <[EMAIL PROTECTED]> wrote:

> At first, I prefer separated binary jar and source jar, because we don't
> need to the source jar in most cases.
>
> As to hadoop, how about we ship two: one with hadoop1, the other with
> hadoop2?
>

  I agree to this.  Actually this will help a lot in case of automatic
scripts that tries to use the tarball.  If not every time the source has to
be recompiled with hadoop 2 and then need to create a tar ball and use it.
 +1 on this.

>
> Thanks,
> Jimmy
>
> On Thu, Mar 21, 2013 at 3:53 PM, Nick Dimiduk <[EMAIL PROTECTED]> wrote:
>
> > There you go again, ignoring my email :p
> >
> > On Thu, Mar 21, 2013 at 3:44 PM, Stack <[EMAIL PROTECTED]> wrote:
> >
> > > I've started in on assemblies for 0.95.  I have a few questions looking
> > at
> > > what we currently have.
> > >
> > > Here is what it looks like when you untar it:
> > >
> > > -rw-r--r--   1 stack  staff  261312 Mar 18 09:27 CHANGES.txt
> > > -rw-r--r--   1 stack  staff   11358 Mar 18 09:27 LICENSE.txt
> > > -rw-r--r--   1 stack  staff     897 Mar 18 09:27 NOTICE.txt
> > > -rw-r--r--   1 stack  staff    1377 Mar 18 09:27 README.txt
> > > drwxr-xr-x  27 stack  staff     918 Mar 18 09:27 bin
> > > drwxr-xr-x   9 stack  staff     306 Mar 20 22:37 conf
> > > drwxr-xr-x  12 stack  staff     408 Mar 19 15:23 dev-support
> > > drwxr-xr-x  67 stack  staff    2278 Mar 21 12:12 docs
> > > drwxr-xr-x   4 stack  staff     136 Mar 21 12:12 hbase-client
> > > drwxr-xr-x   4 stack  staff     136 Mar 21 12:12 hbase-common
> > > drwxr-xr-x   6 stack  staff     204 Mar 21 12:13 hbase-examples
> > > drwxr-xr-x   4 stack  staff     136 Mar 21 12:13 hbase-hadoop-compat
> > > drwxr-xr-x   4 stack  staff     136 Mar 21 12:13 hbase-hadoop1-compat
> > > drwxr-xr-x   4 stack  staff     136 Mar 21 12:13 hbase-it
> > > drwxr-xr-x   4 stack  staff     136 Mar 21 12:12 hbase-prefix-tree
> > > drwxr-xr-x   4 stack  staff     136 Mar 21 12:12 hbase-protocol
> > > drwxr-xr-x   4 stack  staff     136 Mar 21 12:13 hbase-server
> > > drwxr-xr-x   7 stack  staff     238 Mar 21 12:13 hbase-webapps
> > > drwxr-xr-x  68 stack  staff    2312 Mar 21 14:24 lib
> > > drwxr-xr-x   5 stack  staff     170 Mar 21 14:25 logs
> > > -rw-r--r--   1 stack  staff   66716 Mar 21 09:55 pom.xml
> > > drwxr-xr-x   6 stack  staff     204 Mar 18 09:27 src
> > >
> > >
> > > The src dir and the hbase-* module dirs have src in them.  We should
> > > probably have the src all in one place.  I'm thinking that we should
> > have a
> > > hbase-0.95*-bin.tar.gz and a hbase-0.95-src.tar.gz.  And release them
> > > together.  When you untar the src over the bin you will get something
> you
> > > can build if you wanted to (so pom.xml would be over in src).  Any
> > > preferences?
> > >
> > > I need to go through the lib dir and purge the transtiive includes we
> > don't
> > > need.  Its a pain figuring what we do and do not need.  Useful making
> the
> > > evaluation are the fancy hbase-it tools that have been coming in; I can
> > run
> > > suite of tests w/ the runtime and see what breaks.  For hbase-it tests
> to
> > > work, it looks like junit needs to be included as a runtime dependency.
> >  We
> > > ok w/ that?
> > >
> > > What shall we ship?  A single hbase that defaults to hadoop1?  Or we
> > build
> > > a hadoop2 too and ship a binary that includes hadoop2 also?
> > >
> > > Your Release Manager,
> > > St.Ack
> > >
> >
>

On Thu, Mar 21, 2013 at 4:25 PM, Nick Dimiduk <[EMAIL PROTECTED]> wrote:

> On Thu, Mar 21, 2013 at 3:44 PM, Stack <[EMAIL PROTECTED]> wrote:
> I like better hbase-src be a superset of -bin. I should be able to download
> one package if I want runnable, buildable bits; untaring one archive over
> another strikes me as odd.
>
>
I thought this pretty standard practise; could be wrong.

> I need to go through the lib dir and purge the transtiive includes we don't
> > need.  Its a pain figuring what we do and do not need.
>
>
> Maybe maven can help you here, with the dependency:tree target.
>
>
Maven help?  You don't ask maven to help you.  You fight it (We actually
generate dependency reports -- they are not surfaced on the site).

> Useful making the evaluation are the fancy hbase-it tools that have been
> > coming in; I can run suite of tests w/ the runtime and see what breaks.
> >  For hbase-it tests to work, it looks like junit needs to be included as
> a
> > runtime dependency.  We ok w/ that?
> >
>
> As much as I like having a smoketest (and I think hbase-it is a nice
> candidate), it'll be a little messy. In addition to junit, hbase-it will
> bring in other hbase-*-test jars as runtime dependencies too.
>
>
Hmm.  I would love to make a tarball and then when I undo it, run ITs
against it to verify it whether it an RC or it has a change, etc.  Let me
ping Sergey who seemed to be going out of his way to make this work (and
nkewal who recently seems to have gone out of his way to backout junit as
runtime dependency)

> What shall we ship?  A single hbase that defaults to hadoop1?  Or we build
> > a hadoop2 too and ship a binary that includes hadoop2 also?
> >
>
> For 0.95, might as well support both. I'm concerned about test coverage,
> stability on hadoop2 and would hate to see that as a hard-blocker from
> releasing a 0.96 with all these fancy new features the community has been
> waiting (and waiting, and waiting) for.
>

Thats three votes in favor... let me try it.

St.Ack

On 3/22/13, ramkrishna vasudevan <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 22, 2013 at 4:49 AM, Jimmy Xiang <[EMAIL PROTECTED]> wrote:
[...]
>> As to hadoop, how about we ship two: one with hadoop1, the other with
>> hadoop2?
>>
>  I agree to this.  Actually this will help a lot in case of automatic
> scripts that tries to use the tarball.  If not every time the source has to
> be recompiled with hadoop 2 and then need to create a tar ball and use it.
>  +1 on this.

+1 here too

I also like the idea of producing a single -bin tarball that unpacks
into something sane. Spent some time recently hacking on the Bigtop
RPM build for HBase 0.94 to try and deal with the 0.95 layout as is
right now, but had to move on before getting something that works. It
will be much easier for Bigtop, and any user, really, if 0.95 (and
trunk...) looks as much like 0.94 as possible when unpacked from a
dist tarball.

I think it would be good to have a release -> maven jar mapping for hadoop
1 and hadoop2. That is why releasing two artifacts build against Hadoop 1
and 2 respectively makes sense.

See my poor old issue for background, and rightful arguments from
downstream projects:
https://issues.apache.org/jira/browse/HBASE-6929

Having hadoop version appended to the release version would be ugly though.

Enis
On Fri, Mar 22, 2013 at 3:59 PM, Andrew Purtell <[EMAIL PROTECTED]> wrote:

> On 3/22/13, ramkrishna vasudevan <[EMAIL PROTECTED]> wrote:
> > On Fri, Mar 22, 2013 at 4:49 AM, Jimmy Xiang <[EMAIL PROTECTED]>
> wrote:
> [...]
> >> As to hadoop, how about we ship two: one with hadoop1, the other with
> >> hadoop2?
> >>
> >  I agree to this.  Actually this will help a lot in case of automatic
> > scripts that tries to use the tarball.  If not every time the source has
> to
> > be recompiled with hadoop 2 and then need to create a tar ball and use
> it.
> >  +1 on this.
>
> +1 here too
>
> I also like the idea of producing a single -bin tarball that unpacks
> into something sane. Spent some time recently hacking on the Bigtop
> RPM build for HBase 0.94 to try and deal with the 0.95 layout as is
> right now, but had to move on before getting something that works. It
> will be much easier for Bigtop, and any user, really, if 0.95 (and
> trunk...) looks as much like 0.94 as possible when unpacked from a
> dist tarball.
>

Enis:

Agree we should do this (should HBASE-6929 be a blocker?).   How we going
to do it thoug?  It is two poms, right?  Second one would be
hbase-0.95.0-hadoop2?

St.Ack
On Fri, Mar 22, 2013 at 7:02 PM, Enis Söztutar <[EMAIL PROTECTED]> wrote:

> I think it would be good to have a release -> maven jar mapping for hadoop
> 1 and hadoop2. That is why releasing two artifacts build against Hadoop 1
> and 2 respectively makes sense.
>
> See my poor old issue for background, and rightful arguments from
> downstream projects:
> https://issues.apache.org/jira/browse/HBASE-6929
>
> Having hadoop version appended to the release version would be ugly though.
>
> Enis
>
>
> On Fri, Mar 22, 2013 at 3:59 PM, Andrew Purtell <[EMAIL PROTECTED]>
> wrote:
>
> > On 3/22/13, ramkrishna vasudevan <[EMAIL PROTECTED]>
> wrote:
> > > On Fri, Mar 22, 2013 at 4:49 AM, Jimmy Xiang <[EMAIL PROTECTED]>
> > wrote:
> > [...]
> > >> As to hadoop, how about we ship two: one with hadoop1, the other with
> > >> hadoop2?
> > >>
> > >  I agree to this.  Actually this will help a lot in case of automatic
> > > scripts that tries to use the tarball.  If not every time the source
> has
> > to
> > > be recompiled with hadoop 2 and then need to create a tar ball and use
> > it.
> > >  +1 on this.
> >
> > +1 here too
> >
> > I also like the idea of producing a single -bin tarball that unpacks
> > into something sane. Spent some time recently hacking on the Bigtop
> > RPM build for HBase 0.94 to try and deal with the 0.95 layout as is
> > right now, but had to move on before getting something that works. It
> > will be much easier for Bigtop, and any user, really, if 0.95 (and
> > trunk...) looks as much like 0.94 as possible when unpacked from a
> > dist tarball.
> >
>

On Fri, Mar 22, 2013 at 3:59 PM, Andrew Purtell <[EMAIL PROTECTED]> wrote:

> On 3/22/13, ramkrishna vasudevan <[EMAIL PROTECTED]> wrote:
> > On Fri, Mar 22, 2013 at 4:49 AM, Jimmy Xiang <[EMAIL PROTECTED]>
> wrote:
> [...]
> >> As to hadoop, how about we ship two: one with hadoop1, the other with
> >> hadoop2?
> >>
> >  I agree to this.  Actually this will help a lot in case of automatic
> > scripts that tries to use the tarball.  If not every time the source has
> to
> > be recompiled with hadoop 2 and then need to create a tar ball and use
> it.
> >  +1 on this.
>
> +1 here too
>
> I also like the idea of producing a single -bin tarball that unpacks
> into something sane.

Whats 'sane' (smile).

How about this:

durruti:hbase-0.97-SNAPSHOT stack$ ls -la
total 688
drwxr-xr-x  23 stack  staff     782 Mar 22 20:39 .
drwxr-xr-x  15 stack  staff     510 Mar 22 20:38 ..
-rw-r--r--   1 stack  staff  261312 Mar 18 09:27 CHANGES.txt
-rw-r--r--   1 stack  staff   11358 Mar 18 09:27 LICENSE.txt
-rw-r--r--   1 stack  staff     897 Mar 18 09:27 NOTICE.txt
-rw-r--r--   1 stack  staff    1377 Mar 18 09:27 README.txt
drwxr-xr-x  27 stack  staff     918 Mar 18 09:27 bin
drwxr-xr-x   9 stack  staff     306 Mar 20 22:37 conf
drwxr-xr-x  12 stack  staff     408 Mar 22 15:27 dev-support
drwxr-xr-x  68 stack  staff    2312 Mar 22 17:07 docs
drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-client
drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-common
drwxr-xr-x   6 stack  staff     204 Mar 22 17:04 hbase-examples
drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-hadoop-compat
drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-hadoop1-compat
drwxr-xr-x   4 stack  staff     136 Mar 22 17:04 hbase-it
drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-prefix-tree
drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-protocol
drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-server
drwxr-xr-x   7 stack  staff     238 Mar 22 17:03 hbase-webapps
drwxr-xr-x  68 stack  staff    2312 Mar 22 20:38 lib
-rw-r--r--   1 stack  staff   67265 Mar 22 15:25 pom.xml
drwxr-xr-x   6 stack  staff     204 Mar 18 09:27 src
You can do ./bin/start-hbase.sh against this.   The src is all there so you
can do 'mvn install' too.  Docs are there also.

Or do you find the hbase-* + src distracting?  (The hbase-* has .java
flies, etc., in there).  Should these be hidden, or better, off in a
-src.tgz ball?

Thanks lads,
St.Ack

I do find the module dirs a bit distracting. Perhaps they could go into a
-src.tgz ball only. But this is minor. What I meant by 'sane' is being able
to ./bin/hbase ... and get a viable process running.
On Sat, Mar 23, 2013 at 4:52 AM, Stack <[EMAIL PROTECTED]> wrote:

> On Fri, Mar 22, 2013 at 3:59 PM, Andrew Purtell <[EMAIL PROTECTED]>
> wrote:
>
> > On 3/22/13, ramkrishna vasudevan <[EMAIL PROTECTED]>
> wrote:
> > > On Fri, Mar 22, 2013 at 4:49 AM, Jimmy Xiang <[EMAIL PROTECTED]>
> > wrote:
> > [...]
> > >> As to hadoop, how about we ship two: one with hadoop1, the other with
> > >> hadoop2?
> > >>
> > >  I agree to this.  Actually this will help a lot in case of automatic
> > > scripts that tries to use the tarball.  If not every time the source
> has
> > to
> > > be recompiled with hadoop 2 and then need to create a tar ball and use
> > it.
> > >  +1 on this.
> >
> > +1 here too
> >
> > I also like the idea of producing a single -bin tarball that unpacks
> > into something sane.
>
>
>
> Whats 'sane' (smile).
>
> How about this:
>
> durruti:hbase-0.97-SNAPSHOT stack$ ls -la
> total 688
> drwxr-xr-x  23 stack  staff     782 Mar 22 20:39 .
> drwxr-xr-x  15 stack  staff     510 Mar 22 20:38 ..
> -rw-r--r--   1 stack  staff  261312 Mar 18 09:27 CHANGES.txt
> -rw-r--r--   1 stack  staff   11358 Mar 18 09:27 LICENSE.txt
> -rw-r--r--   1 stack  staff     897 Mar 18 09:27 NOTICE.txt
> -rw-r--r--   1 stack  staff    1377 Mar 18 09:27 README.txt
> drwxr-xr-x  27 stack  staff     918 Mar 18 09:27 bin
> drwxr-xr-x   9 stack  staff     306 Mar 20 22:37 conf
> drwxr-xr-x  12 stack  staff     408 Mar 22 15:27 dev-support
> drwxr-xr-x  68 stack  staff    2312 Mar 22 17:07 docs
> drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-client
> drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-common
> drwxr-xr-x   6 stack  staff     204 Mar 22 17:04 hbase-examples
> drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-hadoop-compat
> drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-hadoop1-compat
> drwxr-xr-x   4 stack  staff     136 Mar 22 17:04 hbase-it
> drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-prefix-tree
> drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-protocol
> drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-server
> drwxr-xr-x   7 stack  staff     238 Mar 22 17:03 hbase-webapps
> drwxr-xr-x  68 stack  staff    2312 Mar 22 20:38 lib
> -rw-r--r--   1 stack  staff   67265 Mar 22 15:25 pom.xml
> drwxr-xr-x   6 stack  staff     204 Mar 18 09:27 src
>
>
> You can do ./bin/start-hbase.sh against this.   The src is all there so you
> can do 'mvn install' too.  Docs are there also.
>
> Or do you find the hbase-* + src distracting?  (The hbase-* has .java
> flies, etc., in there).  Should these be hidden, or better, off in a
> -src.tgz ball?
>
> Thanks lads,
> St.Ack
>

--
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

> It is two poms, right?  Second one would be hbase-0.95.0-hadoop2?

Two poms would just cause a mess, no? Can we do it the current way of the
hadoop.profile + the version specified by the command line. I was thinking
like a BUILDING.txt including
To build the release from the source, use:

mvn package -Dhadoop.profile=2.0 -Dhadoop.version=2.0.3-alpha
-Dversion=0.95.0-hadoop2

If won't work, maybe we can do a branch, commit the changes to pom so that
hadoop2 is default, and release the artifacts from there?
Enis

On Mon, Mar 25, 2013 at 1:53 PM, Andrew Purtell <[EMAIL PROTECTED]> wrote:

> I do find the module dirs a bit distracting. Perhaps they could go into a
> -src.tgz ball only. But this is minor. What I meant by 'sane' is being able
> to ./bin/hbase ... and get a viable process running.
>
>
> On Sat, Mar 23, 2013 at 4:52 AM, Stack <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Mar 22, 2013 at 3:59 PM, Andrew Purtell <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On 3/22/13, ramkrishna vasudevan <[EMAIL PROTECTED]>
> > wrote:
> > > > On Fri, Mar 22, 2013 at 4:49 AM, Jimmy Xiang <[EMAIL PROTECTED]>
> > > wrote:
> > > [...]
> > > >> As to hadoop, how about we ship two: one with hadoop1, the other
> with
> > > >> hadoop2?
> > > >>
> > > >  I agree to this.  Actually this will help a lot in case of automatic
> > > > scripts that tries to use the tarball.  If not every time the source
> > has
> > > to
> > > > be recompiled with hadoop 2 and then need to create a tar ball and
> use
> > > it.
> > > >  +1 on this.
> > >
> > > +1 here too
> > >
> > > I also like the idea of producing a single -bin tarball that unpacks
> > > into something sane.
> >
> >
> >
> > Whats 'sane' (smile).
> >
> > How about this:
> >
> > durruti:hbase-0.97-SNAPSHOT stack$ ls -la
> > total 688
> > drwxr-xr-x  23 stack  staff     782 Mar 22 20:39 .
> > drwxr-xr-x  15 stack  staff     510 Mar 22 20:38 ..
> > -rw-r--r--   1 stack  staff  261312 Mar 18 09:27 CHANGES.txt
> > -rw-r--r--   1 stack  staff   11358 Mar 18 09:27 LICENSE.txt
> > -rw-r--r--   1 stack  staff     897 Mar 18 09:27 NOTICE.txt
> > -rw-r--r--   1 stack  staff    1377 Mar 18 09:27 README.txt
> > drwxr-xr-x  27 stack  staff     918 Mar 18 09:27 bin
> > drwxr-xr-x   9 stack  staff     306 Mar 20 22:37 conf
> > drwxr-xr-x  12 stack  staff     408 Mar 22 15:27 dev-support
> > drwxr-xr-x  68 stack  staff    2312 Mar 22 17:07 docs
> > drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-client
> > drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-common
> > drwxr-xr-x   6 stack  staff     204 Mar 22 17:04 hbase-examples
> > drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-hadoop-compat
> > drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-hadoop1-compat
> > drwxr-xr-x   4 stack  staff     136 Mar 22 17:04 hbase-it
> > drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-prefix-tree
> > drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-protocol
> > drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-server
> > drwxr-xr-x   7 stack  staff     238 Mar 22 17:03 hbase-webapps
> > drwxr-xr-x  68 stack  staff    2312 Mar 22 20:38 lib
> > -rw-r--r--   1 stack  staff   67265 Mar 22 15:25 pom.xml
> > drwxr-xr-x   6 stack  staff     204 Mar 18 09:27 src
> >
> >
> > You can do ./bin/start-hbase.sh against this.   The src is all there so
> you
> > can do 'mvn install' too.  Docs are there also.
> >
> > Or do you find the hbase-* + src distracting?  (The hbase-* has .java
> > flies, etc., in there).  Should these be hidden, or better, off in a
> > -src.tgz ball?
> >
> > Thanks lads,
> > St.Ack
> >
>
>
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

+1 on a BUILDING/README that explicitly documents build instructions. It's
good for the release, and it's good for new contributors.

-1 on two poms, release-specific branch, etc.

On Mon, Mar 25, 2013 at 2:00 PM, Enis Söztutar <[EMAIL PROTECTED]> wrote:

> > It is two poms, right?  Second one would be hbase-0.95.0-hadoop2?
>
> Two poms would just cause a mess, no? Can we do it the current way of the
> hadoop.profile + the version specified by the command line. I was thinking
> like a BUILDING.txt including
> To build the release from the source, use:
>
> mvn package -Dhadoop.profile=2.0 -Dhadoop.version=2.0.3-alpha
> -Dversion=0.95.0-hadoop2
>
> If won't work, maybe we can do a branch, commit the changes to pom so that
> hadoop2 is default, and release the artifacts from there?
> Enis
>
> On Mon, Mar 25, 2013 at 1:53 PM, Andrew Purtell <[EMAIL PROTECTED]>
> wrote:
>
> > I do find the module dirs a bit distracting. Perhaps they could go into a
> > -src.tgz ball only. But this is minor. What I meant by 'sane' is being
> able
> > to ./bin/hbase ... and get a viable process running.
> >
> >
> > On Sat, Mar 23, 2013 at 4:52 AM, Stack <[EMAIL PROTECTED]> wrote:
> >
> > > On Fri, Mar 22, 2013 at 3:59 PM, Andrew Purtell <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > On 3/22/13, ramkrishna vasudevan <[EMAIL PROTECTED]>
> > > wrote:
> > > > > On Fri, Mar 22, 2013 at 4:49 AM, Jimmy Xiang <[EMAIL PROTECTED]>
> > > > wrote:
> > > > [...]
> > > > >> As to hadoop, how about we ship two: one with hadoop1, the other
> > with
> > > > >> hadoop2?
> > > > >>
> > > > >  I agree to this.  Actually this will help a lot in case of
> automatic
> > > > > scripts that tries to use the tarball.  If not every time the
> source
> > > has
> > > > to
> > > > > be recompiled with hadoop 2 and then need to create a tar ball and
> > use
> > > > it.
> > > > >  +1 on this.
> > > >
> > > > +1 here too
> > > >
> > > > I also like the idea of producing a single -bin tarball that unpacks
> > > > into something sane.
> > >
> > >
> > >
> > > Whats 'sane' (smile).
> > >
> > > How about this:
> > >
> > > durruti:hbase-0.97-SNAPSHOT stack$ ls -la
> > > total 688
> > > drwxr-xr-x  23 stack  staff     782 Mar 22 20:39 .
> > > drwxr-xr-x  15 stack  staff     510 Mar 22 20:38 ..
> > > -rw-r--r--   1 stack  staff  261312 Mar 18 09:27 CHANGES.txt
> > > -rw-r--r--   1 stack  staff   11358 Mar 18 09:27 LICENSE.txt
> > > -rw-r--r--   1 stack  staff     897 Mar 18 09:27 NOTICE.txt
> > > -rw-r--r--   1 stack  staff    1377 Mar 18 09:27 README.txt
> > > drwxr-xr-x  27 stack  staff     918 Mar 18 09:27 bin
> > > drwxr-xr-x   9 stack  staff     306 Mar 20 22:37 conf
> > > drwxr-xr-x  12 stack  staff     408 Mar 22 15:27 dev-support
> > > drwxr-xr-x  68 stack  staff    2312 Mar 22 17:07 docs
> > > drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-client
> > > drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-common
> > > drwxr-xr-x   6 stack  staff     204 Mar 22 17:04 hbase-examples
> > > drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-hadoop-compat
> > > drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-hadoop1-compat
> > > drwxr-xr-x   4 stack  staff     136 Mar 22 17:04 hbase-it
> > > drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-prefix-tree
> > > drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-protocol
> > > drwxr-xr-x   4 stack  staff     136 Mar 22 17:03 hbase-server
> > > drwxr-xr-x   7 stack  staff     238 Mar 22 17:03 hbase-webapps
> > > drwxr-xr-x  68 stack  staff    2312 Mar 22 20:38 lib
> > > -rw-r--r--   1 stack  staff   67265 Mar 22 15:25 pom.xml
> > > drwxr-xr-x   6 stack  staff     204 Mar 18 09:27 src
> > >
> > >
> > > You can do ./bin/start-hbase.sh against this.   The src is all there so
> > you
> > > can do 'mvn install' too.  Docs are there also.
> > >
> > > Or do you find the hbase-* + src distracting?  (The hbase-* has .java
> > > flies, etc., in there).  Should these be hidden, or better, off in a
> > > -src.tgz ball?

On Mon, Mar 25, 2013 at 2:00 PM, Enis Söztutar <[EMAIL PROTECTED]> wrote:

> > It is two poms, right?  Second one would be hbase-0.95.0-hadoop2?
>
> Two poms would just cause a mess, no? Can we do it the current way of the
> hadoop.profile + the version specified by the command line. I was thinking
> like a BUILDING.txt including
> To build the release from the source, use:
>
> mvn package -Dhadoop.profile=2.0 -Dhadoop.version=2.0.3-alpha
> -Dversion=0.95.0-hadoop2
>
> If won't work, maybe we can do a branch, commit the changes to pom so that
> hadoop2 is default, and release the artifacts from there?
Let me play with version.  We already figured classifier isn't enough.
 Thanks Enis,
St.Ack