[
https://issues.apache.org/jira/browse/RIVER-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983469#action_12983469
]
Peter Firmstone commented on RIVER-300:
---------------------------------------
This might be an opportune time to consider what we need in the Platform, we
might even consider making a separate module for Service API, I've noticed that
some Service API is packaged in jsk-lib.jar
The interesting thing about how Jini has evolved is the handling of namespaces
and ClassLoading.
Preferred class loading was provided as a solution to class resolution and
visibility for ClassLoaders, some issues remain with this strategy, as detailed
in Mike Warres class loading paper.
https://issues.apache.org/jira/secure/attachment/12413650/Java+Classloader+issues+relating+to+Jini+smli_tr-2006-149.pdf
Preferred class loading presents the developer with additional configuration,
which the developer may not always have correctly configured.
The reason preferred class loading exists is to resolve classes from the proxy
namespace or some other namespace (where namespace can be interchanged with
ClassLoader), when those classes might ordinarily be resolved by the
application class loader, with local libraries or classes at the client, that
may cause version conflicts and codebase annotation loss.
So we are now presented with an opportunity, to design a platform, that we will
completely support in a backward compatible fashion, thus not requiring
preferred class loading configuration by default. By providing standard
practices for developers to follow, we can make deployment simpler.
It is therefore in our interests to keep the platform minimal, but to also
include unifying classes like LookupLocatorDiscovery which clients can utilise
as a standard api for multiple forms of discovery (requires some additional
work on our part).
So I propose we define what we want in the platform, then run a ClassDep
analysis to discover what other classes need to be included.
> 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.
