hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: Lets axe 'core' module and make a flat mvn project of no modules
Date Wed, 19 May 2010 19:02:08 GMT
Thanks Paul for the below.   The argument that client/server split is
an objective that we should take on but that it is not a priority at
the moment nor  imminent -- i.e. not for the next release -- and that
there may be a workaround that doesn't require submodules (as Ryan is
asking) helps.

I'm going to cut out the core submodule and make our mvn flat.


On Tue, May 18, 2010 at 11:20 PM, Paul Smith <psmith@aconex.com> wrote:
> On 19/05/2010, at 3:15 PM, Ryan Rawson wrote:
>> One option to handle the client issue would be to publish a minimal
>> dependency set.... is it possible to publish 2 dependency sets?  One
>> for clients, one for extension authors?
> You might be able to do this, but I wonder if it's just not worth it at this stage.  Another
workaround would be to publish Hbase as is, with all the dependencies needed by the server,
and then post some example on the Hbase wiki, or in some documentation somewhere on "how to
depend on hbase, but only use the dependencies you need for client access" by just specifying
an example pom dependency that shows the dependency exclusion list you guys recommend a project
can get away with.
> This still makes the hbase jar a bit 'fat' from a client usage perspective with non-client
access code embedded, but honestly the only people these days that have a legitimate case
for whinging on having slimmer jars are those that need to embed them in an applet and what
to make the load time faster.  I can't see HBase really being in used in this scenario, so
I say "let the jar be fat".
> one of the other rationales for splitting into modules is to keep layer separations,
but that can also be done by using some dependency analysis plugins and defining rules like
"the 'client' package should only ever use code from the 'service' and 'spi' packages" and
then making that a 'build breakage' event.  There's good reasons for this because it'll keep
your design nice and clean, and evil cyclic dependencies can get there and can cause future
havoc (incidentally I ran across a great IntelliJ plugin here called 'Code Navigator' I highly
recommend, it can highlight these sorts of things nicely inside IJ).  But you guys are good
designers, so I'm not sure that's really a risk worth putting in huge layers of defense against.
> Now you have the contribs out, the real need for multi-modules is vanishing quickly.
Go with simple, I don't personally see why 0.21 really should have a client access module
as a release goal, they value really isn't there I think, I can think of more important things
for you guys to do, and I'm sure you can think of even more. :)
> if you need help with the shuffling, let me know, but it should be straight forward now
hopefully. ?
> cheers,
> Paul

View raw message