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
