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. St.Ack On Tue, May 18, 2010 at 11:20 PM, Paul Smith <psm...@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 > > >
