cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Maven: Aggregation and unpublished modules
Date Mon, 18 Apr 2011 09:32:26 GMT
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

* 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).


View raw message