cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aristedes Maniatis <>
Subject Re: Maven: Aggregation and unpublished modules
Date Mon, 01 Aug 2011 06:00:16 GMT
On Sat Jul 30 20:34:00 2011, Christian Grobmeier wrote:
> 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.
> "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
> <>  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
>> 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
>> 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
>> 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

I don't know that solves our problem from my initial understanding. 
Shade will rename the classes, where our main problem is our hierarchy 
of poms. We have an artificially flattened hierarchy to avoid end users 
seeing a regular maven pom tree.

I don't see how Shade will create anything but an enormous mess between 
svn source, jar output, javadocs and bug reports.

Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

View raw message