cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject back to monolithic cayenne.jar?
Date Sat, 16 Nov 2013 21:11:19 GMT
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-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.


View raw message