FAQ
I started this reorg with less consequential things, like build tools, etc. However after this commit, you may have to delete all your projects in Eclipse workspace, and reimport. Took a total of 1 min for me.

The next round of changes will likely require another reimport. Sorry for the inconvenience.

A.

On Nov 15, 2013, at 10:29 PM, Andrus Adamchik (JIRA) wrote:


[ https://issues.apache.org/jira/browse/CAY-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13823988#comment-13823988 ]

Andrus Adamchik commented on CAY-1883:
--------------------------------------

Just committed the first batch of changes - mostly clearing the workspace... :

* organized buildtools hierarchy according to Maven conventions.
* Moved cayenne-legal-unpublished to buildtools. buildtools happens to be "unpublished" folder by definition, so new name is just "cayenne-legal"
* moved cayenne-wocompat-unpublished to modeler where it is used.
Clean up Cayenne maven structure - get rid of aggregate modules
---------------------------------------------------------------

Key: CAY-1883
URL: https://issues.apache.org/jira/browse/CAY-1883
Project: Cayenne
Issue Type: Task
Affects Versions: 3.2M2
Reporter: Andrus Adamchik
Assignee: Andrus Adamchik
Fix For: 3.2M2


Reorg Cayenne Maven structure, making cayenne-server and cayenne-client real Maven modules instead of aggregates. Use <optional> and “provided” dependencies to exclude the extras like JGroups and keep it clean.
Immediate motivation is OSGi integration that is not possible to achieve cleanly without this reorg.


--
This message was sent by Atlassian JIRA
(v6.1#6144)

Search Discussions

  • Andrus Adamchik at Nov 16, 2013 at 9:11 pm
    So after poking around our sources, I wonder if we should rethink our module boundaries. Since we are talking OSGi, the decision that we make now is kind of important, as module definitions will become as exposed as classes and packages.

    The main rule of modularity goes smth. like this: “coarse-grained modules are more useable, fine-grained modules are more reusable” .. Just taking runtime into consideration, potentially we can be anywhere from a single monolithic cayenne.jar (hi, Cayenne 1.0 :)) to a system with about a dozen modules.

    At least bandwidth is no longer a consideration, so those 800K that we saved by trimming cayenne-client doesn’t have to enter this discussion anymore. Neither should we be concerned with various Maven hacks - I cleaned those up completely (e.g. JDK-specific modules, if they are to appear in the future, will likely be handled via DI, not by Maven cheating). Now it is all about proper API isolation vs. not driving users crazy with trying to figure out which jars they need. Here are two examples that appear to be pretty reasonable:

    1. Monolithic cayenne.jar for regular apps, for ROP clients, for CayenneModeler

    pros: easy to understand for the end users - whole runtime is in one jar.
    cons: too many things are mixed together, easy to create unintended internal dependencies

    2. Partial modularity - Client/server split between the modules, with separate DI and backend-indepdendent “core” :

      cayenne-di.jar
      cayenne-core.jar
      cayenne-server.jar => cayenne-di, cayenne-core
      cayenne-client.jar => cayenne-di, cayenne-core (and possibly cayenne-server)

    pros: Some modularity, exposing DI for standalone use and preventing ROP clients and
              CayenneModeler from inadvertently accessing JDBC access stack classes.
           Jar names are backwards compatible with 3.1
    cons: Non-Maven users will have more than one jar to import (in fact they will have 3).
           Things are still mixed together, but to a lesser degree.

    Anyways, these are our options… Feel free to comment, while I continue my refactoring.

    Andrus
  • Adrian A. at Nov 16, 2013 at 9:28 pm

    1. Monolithic cayenne.jar for regular apps, for ROP clients, for CayenneModeler
    2. Partial modularity - Client/server split between the modules, with separate DI and backend-indepdendent “core” :
    ...
    Anyways, these are our options… Feel free to comment, while I continue my refactoring.
    What about offering both? The modules, but also a "cayenne-all.jar"
    (or simply "cayenne.jar") ?


    Adrian
  • Andrus Adamchik at Nov 16, 2013 at 9:49 pm

    On Nov 17, 2013, at 12:27 AM, Adrian A. wrote:

    1. Monolithic cayenne.jar for regular apps, for ROP clients, for CayenneModeler
    2. Partial modularity - Client/server split between the modules, with separate DI and backend-indepdendent “core” :
    ...
    Anyways, these are our options… Feel free to comment, while I continue my refactoring.
    What about offering both? The modules, but also a "cayenne-all.jar"
    (or simply "cayenne.jar") ?


    Adrian
    This will take us back to aggregation of multiple modules into one. It was not a pretty picture, so now I am *hoping* we can align the source modules with the binaries that we release. However this can be an option for non-maven users I guess.

    A.
  • Andrus Adamchik at Nov 17, 2013 at 10:05 am
    Now that I gave it some thought, I actually like the idea of a system modular by default, but including cayenne-all.jar on top of that. It has none of the drawbacks of our old “synthetic” cayenne-server and cayenne-client. More practically, turns out that cleanly splitting the core and server classes is much more effort than I am ready to undertake now. So we ended up with these modules:

      cayenne-di.jar
      cayenne-server.jar => cayenne-di
      cayenne-client.jar => cayenne-di, cayenne-server

    I guess I’ll leave it at that until a later time when we can cut smaller modules out of cayenne-server.

    Andrus

    On Nov 17, 2013, at 12:49 AM, Andrus Adamchik wrote:
    On Nov 17, 2013, at 12:27 AM, Adrian A. wrote:

    1. Monolithic cayenne.jar for regular apps, for ROP clients, for CayenneModeler
    2. Partial modularity - Client/server split between the modules, with separate DI and backend-indepdendent “core” :
    ...
    Anyways, these are our options… Feel free to comment, while I continue my refactoring.
    What about offering both? The modules, but also a "cayenne-all.jar"
    (or simply "cayenne.jar") ?


    Adrian
    This will take us back to aggregation of multiple modules into one. It was not a pretty picture, so now I am *hoping* we can align the source modules with the binaries that we release. However this can be an option for non-maven users I guess.

    A.
  • Mike Kienenberger at Nov 18, 2013 at 1:33 pm
    This one looks good to me..
    On Sun, Nov 17, 2013 at 5:05 AM, Andrus Adamchik wrote:
    Now that I gave it some thought, I actually like the idea of a system modular by default, but including cayenne-all.jar on top of that. It has none of the drawbacks of our old “synthetic” cayenne-server and cayenne-client. More practically, turns out that cleanly splitting the core and server classes is much more effort than I am ready to undertake now. So we ended up with these modules:

    cayenne-di.jar
    cayenne-server.jar => cayenne-di
    cayenne-client.jar => cayenne-di, cayenne-server

    I guess I’ll leave it at that until a later time when we can cut smaller modules out of cayenne-server.

    Andrus

    On Nov 17, 2013, at 12:49 AM, Andrus Adamchik wrote:
    On Nov 17, 2013, at 12:27 AM, Adrian A. wrote:

    1. Monolithic cayenne.jar for regular apps, for ROP clients, for CayenneModeler
    2. Partial modularity - Client/server split between the modules, with separate DI and backend-indepdendent “core” :
    ...
    Anyways, these are our options… Feel free to comment, while I continue my refactoring.
    What about offering both? The modules, but also a "cayenne-all.jar"
    (or simply "cayenne.jar") ?


    Adrian
    This will take us back to aggregation of multiple modules into one. It was not a pretty picture, so now I am *hoping* we can align the source modules with the binaries that we release. However this can be an option for non-maven users I guess.

    A.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriescayenne
postedNov 15, '13 at 7:31p
activeNov 18, '13 at 1:33p
posts6
users3
websitecayenne.apache.org

People

Translate

site design / logo © 2022 Grokbase