Re: Using Eclipse with Mavenized Cayenne - http://cayenne.apache.org/eclipse.html

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Thu Mar 01 2007 - 12:27:42 EST

  • Next message: Mike Kienenberger: "Documenting the modules / Documenting the sets of functionality"

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

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

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

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

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

    Andrus



    This archive was generated by hypermail 2.0.0 : Thu Mar 01 2007 - 12:29:13 EST