[
https://issues.apache.org/jira/browse/RIVER-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988515#action_12988515
]
Peter Firmstone commented on RIVER-300:
---------------------------------------
Many classes in the existing build, belonging to the com.sun.jini.* namespace
are duplicated in jar archives, these are implementation classes, the
preferred class loading mechanism is used to ensure that the codebase copy /
version is used by proxy's, not the classpath version of a class.
Preferred class loading prevents the loading of jini implementation classes
from the Classpath (application class loader) by proxy's or services in their
own namespace (a child classloader).
If we create a modular system, these implementation classes duplicated in many
archives currently, will need to be separated into their own module, in order
to allow them and the modules that depend on them, to evolve separately, since
a proxy will need to be able to use the version it requires, while the platform
can use another version.
Preferred class loading, is the current mechanism that should be used to assist
with version control, to ensure that proxy's load the correct implementation
classes. This allows TaskManager and suchlike to evolve without concern for
backward compatibility, and it allows services and proxy's to use their own
version copies, in their own private name space.
Preferred class loading is required to prevent the use of classes from the
classpath (application class loader)
In a modular system, the source code belongs in a particular module and is not
duplicated, classes are also not duplicated. The class files that are
currently duplicated belong in their own modules, on which the platform and
other modules depend.
This is at present, the only way to prevent us from having to support the
duplicated implementation classes as part of the platform.
Eventually I can see the potential to refactor using JDepend and dependency
inversion, removing jini platform implementation classes from the classpath,
instead loading them into a private namespace (child classloader), when this is
done, preferred class loading will no longer be mandatory, as there is no
danger of proxy's using the local class path version of these classes, since
they won't be visible in the parent application classloader.
> 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.
