Perhaps we could agglomerate the modules, in the case below however,
this would make river-platform depend on river-lib, which depends on
river-dl, due to other dependencies and we don't really want that either.
In practise I was able to eliminate the circular dependencies in JGDMS
without much difficulty, it was some time ago now, so I'm a little rusty
on the details, but I'll go over my commit history and find out.
At some point we'll want to upgrade river-iiop to depend on external
modules so it can be supported in later versions of Java, so there's an
argument to keep it out of the platform module to reduce platfrom
dependencies on external libs.
One benefit of smaller modules is the ability to focus on a smaller
amount of code for developers to digest how a module works without
needing to understand code in other modules. The benefit of the larger
module is the ability to absorb the circular dependencies without having
to untangle them, but this tends towards a monolith again.
Cheers,
Pete.
On 7/7/2020 6:04 AM, Dennis Reedy wrote:
Hio all,
I thought I'd take a look at the work going on with the modularization
effort, and aside from just trying to get the project built (still doesnt),
I have some questions on the rationale on how it's been broken into its
constituent modules (sub-projects).
Some of the breakup causes circular dependencies ( river-platform <->
river-jeri), and some seem questionable. What I'd like to suggest is a
slight re-organization. For the bulleted lists below, the indented project
should be added to the enclosing project (example: add the code from
river-jeri into the river-platform project and remove river-jeri). This
simplifies the project and removes circular dependencies.
- river-platform
- river-jeri
- river-iiop
- river-url-integrity
- river-pref-loader
- river-lib
- river-destroy
- river-collections
- river-phoenix
- river-start
- river-activation
Thoughts?
Regards
Dennis Reedy
