The original idea of having "private" (aka "unpublished") modules that are aggregated into bigger public modules was about consistent picture that we wanted to present to the end users.
I always imagined ideal Cayenne as a self-contained drag-and-drop lib that does not require special installation, and ideally has no third-party dependencies. It originated from the earlier days of manual CLASSPATH, but some of this has merit these days as well. Third-party dependencies have version conflicts with same dependencies coming from other libs, so we worked on reducing the number of them (in 3.1 it is just c-collections which should go too, c-logging and velocity.). Now a single Cayenne jar does not have direct technical benefits. In a way it is a "feel good" thing these days. However let's look at the factors that led us to creating it: 1. Cross JDK builds. We don't have it in this iteration, but we used to have it before and may have it in the future. A single jar would provide features of the newer Java under newer JRE, and seamlessly degrade under older JRE (e.g. that's how we implemented annotations support). 2. cayenne-client.jar optimized for size. We never had a clean separation between cayenne-common, cayenne-server and cayenne-client. So cayenne-client was a stripped-down version of cayenne-server without the DB connection layer. This is another kludge from the Ant days. And another dimension in addition to JDK. So say we refactor everything, merge cayenne-di with parts of cayenne-server into a new cayenne-common, remove all the kludges and start supporting Java 9 extensions. The runtime modules will be these: * cayenne-common.jar (say we merge di in here) * cayenne-common-java9.jar * cayenne-server.jar * cayenne-server-java9.jar * cayenne-client.jar * cayenne-client-java9.jar plus some build or other extensions: * cayenne-project.jar * cayenne-tools.jar * cayenne-lifecycle.jar So should we aggregate them for downloadable distro, but not Maven? Should we give up on aggregation completely and use other means to reduce confusion? (Also notice that I am not touching the Modeler in this discussion as the Modeler distro is opaque and we can reorganize it internally as much as we'd like. I am only concerned about the runtime libraries and somewhat about the build tools). Andrus
