Comments inline.
On 3/1/07, Andrus Adamchik wrote:
Believe it or now the structure is pretty well thought out. It may
not be obvious, but documentation should help with this.
I don't doubt it. Here's to more documentation :-) Let's see what we can do.

On Mar 1, 2007, at 6:47 PM, Mike Kienenberger wrote:
I took a look at the svn folder layout.

- jpa-chapter-* and pojo are integration tests? Definitely not
obvious from the module names.
It is obvious :-) The full path is "itests/jpa-chapter*"
Well, you only see this if you're working with the raw svn checkout.
You don't see this in Eclipse, nor when you import the project into

I also don't understand the difference between assemblies and build-
Assemblies are the release archives in Maven speak. I didn't invent
it :-) Build tools are used to build all modules. There is nothing
common between them.
Fair enough. But from a developer point of view, they both "seem" to
be stuff dealing with making maven build it. If I don't care about
how things get built, I don't care about this set of code.
I see both a modeler and a framework/cayenne-modeler directory.
This is correct. "framework/cayenne-modeler" is a modeler *library*,
while "modeler/*" are modules serve to produce Modeler *application*
for a given platform. This distinction was introduced because there
was no other way to handle this in Maven, but there is still common
logic behind it.
Ok. So modeler/ is mostly more build tools. (I know, there's
probably some GUI framework stuff in there too, but I'm guessing this
is stuff that would not be changed at the cayenne project).
I see maven-cayenne-plugin in the framework directory. Isn't this a
No, this is a Maven analog of cgen - i.e. a plugin that we release to
the users.
Ugh. I really wish you'd named it differently, then. Like
maven-cayenne-cgen-plugin. I'm guessing it might ahve more than cgen
in it, but still, this module name looks like more maven
infrastructure as it stands.

I see the regression/profiler in build tools. How is that different
from integration tests as a separate directory.
Regression profiler doesn't belong anywhere really. It is probably
the only module with a randomly chosen location waiting its time. It
is excluded from the main build anyways.
It's a form of testing.

Also, I'm not certain that breaking the testing up separately from
everything else makes sense, but if the tests aren't separated by the
major sets (cayenne classic, JPA, modeler, cgen, ROP), I don't know
what other way makes sense.
There's no breakdown between JPA-specific pieces and classic Cayenne. There is.
There's also no break out of the ROP stuff. Correct.
Since these various pieces are in separate modules, I would think a
module description
would keep them separate as well. I'm sure it's a matter of
I don't completely follow, do you mean we need more fine-grained
modules? I don't disagree, but there are two more dimensions (in
addition to the "logical split" dimension) that make it harder: the
need to maintain JDK 1.4/1.5 split and the need to maintain user vs.
developer view ("unpublished" vs "published").

In fact I proposed in the past to split a few secondary modules for
ease of reuse (connection pool and wocompat). I was going to mention
that separate from this discussion.
No, I'm not really saying that we need more breakdown (although that
might be true). What I was saying is that my preference would be to
see it organized (at least on the Eclipse page) around sets of major
functionality. If my primary interest is Cayenne Classic, I want to
know what sets of modules that includes. If my primary interest is
the modeler, again, which sets do I want to work wtih? And so on for
cgen, JPA, ROP, documentation, and tutorials (did I miss anything

Search Discussions

Discussion Posts

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 1 of 4 | next ›
Discussion Overview
groupdev @
postedMar 1, '07 at 11:39p
activeMar 4, '07 at 4:27a



site design / logo © 2022 Grokbase