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