[
https://issues.apache.org/jira/browse/RIVER-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983998#action_12983998
]
Peter Firmstone commented on RIVER-300:
---------------------------------------
Modularisation of the directory structure and build of river is a large task,
which might be used to replicate the current release artifacts, with the
following exceptions:
Due to the dependency nature and structure of a modular build (see Dennis
Reedy's attached river-modularisation-overview), certain classes provided by
primary modules are excluded from dependent modules, contrary to the existing
build, where all dependent classes other than platform api classes are included.
It is also worth noting modular dependency's and build structures are very
relevant to Service API, to the implementation of services and proxy's and
simplified development, which is possibly the main attraction of modular
development frameworks.
With existing Jini and River releases, each client can potentially have a
different plethora of classes loaded by it's application class loader,
preferred class loading has been provided to deal with this, which brings
another set of issues, documented by Mike Warres.
Sometimes change is an opportunity to consider other changes, such as the
namespace change from com.sun.jini to org.apache.river, this is currently in
the experimental stages and we're not certain if this should be done at the
same time, but I'd like to keep the option open for now.
Client developers have been made aware of a policy that com.sun.jini are
implementation classes only and not to be used, however a number of useful
utility classes are included in com.sun.jini and will likely cause some client
breakage (not proxys which have preferred class loading), when they're moved.
Making the build modular also makes our service implementations (that client
developers are also free to implement) depend on parts of the build that are
implementation only.
Considering that the only thing guaranteed to be installed at all clients is
the platform jar, it is typical for service proxy's to have all needed classes
available to them via download, utilising preferred class loading to ensure
these classes are loaded, and not substituted by classes already loaded in the
application class loader. So even with a modular build, there is still a need
to maintain a level of compatibility with existing installations. In reality
we will need to provide a jar file containing all the classes needed by proxy's
downloaded to legacy clients.
In an ideal world, the application class loader would only contain classes and
interfaces that are used by proxy's, client's and services to communicate with
each other, child class loaders representing private namespaces would contain
all implementation classes. In this world, preferred class loading would not
be required and annotation loss would not occur. If the application
classloader only contained service api and the jini platform, then a number of
existing issues would disappear.
So the question remains: Why was the current platform jar structured how it is
now?
What are the reasons and logic behind it's current design?
I think these are questions we need to ask as we explore the possibilities of a
modular build structure.
> 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,
> 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.
