cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Grobmeier <grobme...@gmail.com>
Subject Re: Maven: Aggregation and unpublished modules
Date Mon, 18 Apr 2011 10:09:44 GMT
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 are aggregated
into bigger public modules was about consistent picture that we 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 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.).


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 way it is a "feel
good" thing these days. However let's look at the factors that 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 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).

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


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

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

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

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



-- 
http://www.grobmeier.de

Mime
View raw message