[
https://issues.apache.org/jira/browse/RIVER-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988456#action_12988456
]
Peter Firmstone commented on RIVER-300:
---------------------------------------
I can see where Dennis is coming from, Renaming river-dl.jar to river-api.jar,
since this jar is depended upon by river-lib.jar, so in a modular build, the
class files in river-dl.jar and river-lib.jar are not duplicated, requiring
both these jar files to be loaded by applications utilising river-lib.jar.
The minimum requirements for a Jini environment is the platform.jar, so the
river-dl.jar still needs to be downloaded where the client node lacks the
classes a proxy needs that are provided by river-dl.jar. In this case those
class files will be loaded into the proxy's classloader.
Client in this case refers to a node that doesn't contain river-lib.jar or
river-dl.jar on the classpath. This doesn't mean this client doesn't also
provide services to other nodes, although this configuration would be rare.
River-lib.jar contains a lot of useful jar files also, such as additional
service api and service management utilities.
What I have noted is the platform.jar contains a minimal number of
implementation classes, while river-lib.jar contains a lot.
So perhaps we should do as Dennis has suggested and just make the modular build
an exercise in mostly replicating the current build, albeit without class
duplication. Although as Gregg has pointed out, we must be careful to consider
compatibility.
I was reading the JDepend website, I think Chris can see where I'd like to go,
thanks for the info & links:
"Invert Dependencies
The goal of using JDepend is to ultimately invert package dependencies such
that low-abstraction packages depend upon high-abstraction packages. This
inversion of dependencies allows the high-abstraction packages to be reused
independently while being extensible to an open set of implementations. In
general, dependencies upon stable packages are desirable, while dependencies
upon instable packages are undesirable. JDepend allows dependencies to be
iteratively examined and refactored as an integral part of software design and
development. "
Seems like a good long term goal.
When the package dependencies have been inverted, the implementations can go
into child class loaders, while the high abstraction packages become the common
classes that proxy's, applications and services use to communicate with each
other belong in the parent application class loader.
Implementation classes belong in child classloaders with application, proxy and
service implementations. Allowing more flexibility and evolution of
implementations.
This does make me realise though we'll need to load river-lib.jar into the
applicaiton class loader for some time.
> introduce maven to the river build process
> ------------------------------------------
>
> Key: RIVER-300
> URL: https://issues.apache.org/jira/browse/RIVER-300
> Project: River
> Issue Type: Improvement
> Components: build
> Reporter: Jools Enticknap
> Attachments: apache-river-gradle.zip, apache-river-maven.zip,
> ldm.pdf, lld.pdf, persistOutrigger.pdf, river-modularization-overview.odt,
> river-modularization-overview.pdf
>
>
> Currently the river build using ant, but it's a custom build process and has
> many hang overs from the original make build.
> Given that the project has no 3rd party dependencies, it would be very easy
> to break the code up into modules.
> Please feel free to add to this JIRA if you have any opinions on how the
> maven repository should be setup.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
