[
https://issues.apache.org/jira/browse/RIVER-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986196#action_12986196
]
Gregg Wonderly commented on RIVER-300:
--------------------------------------
Peter, there is one very important constraint that we have to deal with. It
has to be possible to unmarshal any services proxy that you can lookup,
regardless of what classes are in your VM. The proxy's codebase must contain a
version of everything needed to use the proxy. This means that you can't
really take a "service' vs 'client' view of class segregation. The classes,
interfaces must be "everywhere". The key separation of the service vs -dl jar
file is simply the fact that you don't want "implementation" in the classpath,
only in the codebase. Any other commoning of classes, for me, is a deal
breaker because it greatly changes the opportunity that more than one service
will be dependent on a "jar" that you change on a web server, and keep services
from being independent of each other.
> 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.
