Comments inline.
On 3/1/07, Andrus Adamchik <andru..bjectstyle.org> 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
eclipse.
> > I also don't understand the difference between assemblies and build-
> > tools.
>
> 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
> > build-tool/assembly?
>
> 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
> > perspective.
>
> 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
else)?
This archive was generated by hypermail 2.0.0 : Thu Mar 01 2007 - 18:40:25 EST