We use a seperate project for all objects that are common between the
client and server classes, which includes the rmi stub...
(which is a post goal to java:compile btw). Not too much classes in the
project though, but it works well. (the common.jar has no external
dependencies at all).
Mvgr,
Mar
Jason van Zyl wrote:
On Thu, 2004-07-01 at 11:35, Laszlo Papp wrote:
Is there a clear solution for this kind of problematic ?
This is actually one of the nastiest use cases we are trying to sort out
at the moment. All RMI-based solutions do this sort of thing and we're
definitely working on a sol
Mark Church wrote:
What about a 3rd project that contains Impl.java? Both the client and
server projects could then depend on this project.
Mark Church
Hi,
It would look better but it would still violate the concept of the
preferred DAG (Directed Acyclic Graph) dependency graphs...
Between th
On Thu, 2004-07-01 at 11:35, Laszlo Papp wrote:
>
> Is there a clear solution for this kind of problematic ?
This is actually one of the nastiest use cases we are trying to sort out
at the moment. All RMI-based solutions do this sort of thing and we're
definitely working on a solution. This viol
What about a 3rd project that contains Impl.java? Both the client and
server projects could then depend on this project.
Mark Church
Laszlo Papp wrote:
Hi all,
We have tried to compile and distibute a client/server
architecture based on RMI and had to face some difficulties which seem
to b
Hi all,
We have tried to compile and distibute a client/server architecture
based on RMI and had to face some difficulties which seem to be lying on
the basic concept of the Maven environment (namely that one project is
only able to produce and distribute one and only JAR file).
We have set up
