hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Angeles <patr...@cloudera.com>
Subject Re: Lets axe 'core' module and make a flat mvn project of no modules
Date Wed, 19 May 2010 15:45:28 GMT
FWIW, I'm +1 on keeping client and server separate if possible. For one
thing, the dev and upgrade cycles may be different on these.

You could actually spin out client into its own project. No need to keep it
under the same multi-module pom but that might prove harder to work with.

WRT to multi-module reporting with mvn, I agree, that's a bit of a pain but
at least it's not a required part of a successful build.

On Wed, May 19, 2010 at 5:12 AM, Stack <stack@duboce.net> wrote:

> Today we got rid of contrib out of TRUNK.  All contribs been moved out
> to github -- transactional hbase, indexed hbase, ec2 scripts -- or
> pulled up into core (stargate REST server and replication).  Now we
> have only core.  core has its on pom.xml.  Its a maven "module" (or
> submodule(?)) of the hbase maven project.
> I want to remove it.  It seems silly having a maven build of a single
> module only.  It complicates the build; e.g. if you do mvn site, only
> the reports under the core module have any meat to them; those of the
> parent project are mostly empty.
> Upside:
> Simpler maven build; one artifact made only, the hbase jar.
> Downsides:
> It took a work getting the module infrastructure into place.  We'd be
> undoing it.
> While we have only one module now, the future may bring hbase
> submodules.  The looming one is a client hbase module; i.e. core would
> be split into at least hbase-server and hbase-client.  Undoing the
> modules and then bringing them back later should we go ahead on
> hbase-server+hbase-client would be disruptive.
> I'm for simplifying our build.  Maven is pain enough.  What do others
> think?  Mostly, it'd involve pulling the content of core up a level
> and merging the core pom w/ the main hbase pom.
> St.Ack

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message