Today I read a suggestion from Mark Struberg on the Commons Dev list about a pretty cool maven plugin. It might help on the sleeping discussion of reorganizing the mvn structure.
http://maven.apache.org/plugins/maven-shade-plugin/ "This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and to shade - i.e. rename - the packages of some of the dependencies." With this package, Cayenne might provide cayenne-server/client jars for the "normal users" without touching the mvn layout which is expected by a developer. I have not used it before, but would like throw that into the discussion. What do you think of it? Cheers Christian On Mon, Apr 18, 2011 at 11:32 AM, Andrus Adamchik <[email protected]> wrote: > 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 > > > -- http://www.grobmeier.de
