Mailing-List: contact dev-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cayenne.apache.org
Received-SPF: pass (athena.apache.org: domain of grobmeier@gmail.com
 designates 209.85.210.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        b=YjBTeEhu2FGDGO98V3ZeqnbajjICatdfpRpr48uv/XRlXiukc6iVr9dDe5/kDzP0T3
         +araAeFuMEpDlz66MQUppuFChsIa6hOfvAwrsz5gD6kGKE6YRGETE4YTwlZVI/X8ayYd
         z0gTs3EpjFewO1IZ0cse6dT9mg5o4hd4h5RCU=
MIME-Version: 1.0
In-Reply-To: <A456C611-F5F7-4FF7-BC66-48443CDA20F7@objectstyle.org>
References: <A456C611-F5F7-4FF7-BC66-48443CDA20F7@objectstyle.org>
From: Christian Grobmeier <grobmeier@gmail.com>
Date: Mon, 18 Apr 2011 12:09:44 +0200
Message-ID: <BANLkTi=5c=_+2NjvUzVQfitaTzGFt2x6ag@mail.gmail.com>
Subject: Re: Maven: Aggregation and unpublished modules
To: dev@cayenne.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello,

I can only answer from a user perspective now. I have started to dig a
little more deep into Cayenne and found the current maven usage very
confusing. I prefer to learn one thing (mvn) and then use it all over
the time. It was really shocking for me this is not the case with
Cayenne. Its like opening source code and the brackets are on the
wrong line, like in Wicket ;-)

> The original idea of having "private" (aka "unpublished") modules that ar=
e aggregated into bigger public modules was about consistent picture that w=
e wanted to present to the end users.

In these mvn days people seem to drill down their apps to small jars.
I don't see a benefit of one big jar anymore. Mvn (and in ant world
ivy) is getting all necessary jars for me - I really don't care.

With one exception: if i want to download for example a json lib and
it has a dependency to a code generator of a specific version. In this
case I care because I am afraid another jar dependency is using the
same dependency in another version.

But I would not mind if I have 5 cayenne jars (or more, or less). I
know this situation from frameworks like Spring or Hibernate.


> I always imagined ideal Cayenne as a self-contained drag-and-drop lib tha=
t does not require special installation, and ideally has no third-party dep=
endencies. It originated from the earlier days of manual CLASSPATH, but som=
e of this has merit these days as well. Third-party dependencies have versi=
on 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.).


Reducing dependencies is another story - and I actually like the small
third party libs idea of cayenne. But a reduced number of libs and a
huge aggregated jar of self-written classes are two different shoes
imho


> Now a single Cayenne jar does not have direct technical benefits. In a wa=
y it is a "feel good" thing these days. However let's look at the factors t=
hat led us to creating it:

I agree - I remember the pain when maven was not there (or ivy)


> 1. Cross JDK builds. We don't have it in this iteration, but we used to h=
ave it before and may have it in the future. A single jar would provide fea=
tures of the newer Java under newer JRE, and seamlessly degrade under older=
 JRE (e.g. that's how we implemented annotations support).

How is Hibernate doing it? They have a similar feature with their annotatio=
ns.
Probably there is a chance to solve this with maven profiles.


> So say we refactor everything, merge cayenne-di with parts of cayenne-ser=
ver into a new cayenne-common, remove all the kludges and start supporting =
Java 9 extensions.

Java 9 extensions? Can you give more information - I don't know what you me=
an

>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? Shoul=
d we give up on aggregation completely and use other means to reduce confus=
ion?

Imho:
Use a standard maven build. No aggregation. In other terms, the jars
you mentioned a perfectly understandable. I can fully accept each of
them in my app as a dependency. Still my app has a dependency to
cayenne-server.jar only. cayenne-server.jar does care bout its
dependencies.

If one wants a downloadable distro - we can create an assembly.xml for
that. I think even aggregated builds are easily possible with an
assembly file:
<descriptorRef>jar-with-dependencies</descriptorRef>
http://maven.apache.org/plugins/maven-assembly-plugin/usage.html

my 2 cents- but I am in full favour of this approach as you probably
have seen in an email before a few days (which was not the easy to
understand, I admit).

Cheers,
Christian

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


--=20
http://www.grobmeier.de