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.Believe it or now the structure is pretty well thought out. It may
not be obvious, but documentation should help with this.
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*"I took a look at the svn folder layout.
- jpa-chapter-* and pojo are integration tests? Definitely not
obvious from the module names.
You don't see this in Eclipse, nor when you import the project into
eclipse.
I also don't understand the difference between assemblies and build-
tools.
Assemblies are the release archives in Maven speak. I didn't inventtools.
it :-) Build tools are used to build all modules. There is nothing
common between them.
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.
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
build-tool/assembly?
No, this is a Maven analog of cgen - i.e. a plugin that we release tobuild-tool/assembly?
the users.
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 probablyfrom integration tests as a separate directory.
the only module with a randomly chosen location waiting its time. It
is excluded from the main build anyways.
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
perspective.
I don't completely follow, do you mean we need more fine-grainedThere'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
perspective.
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.
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
else)?
