+1 Simplicity is key
On 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 > >
