So after poking around our sources, I wonder if we should rethink our module
boundaries. Since we are talking OSGi, the decision that we make now is kind of
important, as module definitions will become as exposed as classes and packages.
The main rule of modularity goes smth. like this: “coarse-grained modules are
more useable, fine-grained modules are more reusable” .. Just taking runtime
into consideration, potentially we can be anywhere from a single monolithic
cayenne.jar (hi, Cayenne 1.0 :)) to a system with about a dozen modules.
At least bandwidth is no longer a consideration, so those 800K that we saved by
trimming cayenne-client doesn’t have to enter this discussion anymore. Neither
should we be concerned with various Maven hacks - I cleaned those up completely
(e.g. JDK-specific modules, if they are to appear in the future, will likely be
handled via DI, not by Maven cheating). Now it is all about proper API
isolation vs. not driving users crazy with trying to figure out which jars they
need. Here are two examples that appear to be pretty reasonable:
1. Monolithic cayenne.jar for regular apps, for ROP clients, for CayenneModeler
pros: easy to understand for the end users - whole runtime is in one jar.
cons: too many things are mixed together, easy to create unintended internal
dependencies
2. Partial modularity - Client/server split between the modules, with separate
DI and backend-indepdendent “core” :
cayenne-di.jar
cayenne-core.jar
cayenne-server.jar => cayenne-di, cayenne-core
cayenne-client.jar => cayenne-di, cayenne-core (and possibly cayenne-server)
pros: Some modularity, exposing DI for standalone use and preventing ROP
clients and
CayenneModeler from inadvertently accessing JDBC access stack classes.
Jar names are backwards compatible with 3.1
cons: Non-Maven users will have more than one jar to import (in fact they will
have 3).
Things are still mixed together, but to a lesser degree.
Anyways, these are our options… Feel free to comment, while I continue my
refactoring.
Andrus
