Thanks Mike,
I've had some thoughts about breaking the build into components
something like this:
jini-platform.jar (net.jini.*, org.apache.river.api.*)
jini-policy.jar
jini-resources.jar
river-lib.jar
river-impl.jar (com.sun.*, org.apache.river.impl.*, common
implementation files)
*service-api.jar (one for each service).
eg:
lookup-service-api.jar
transaction-service-api.jar
lease-service-api.jar
Then all the service implementations proxy's eg:
Reggie-impl.jar
Reggie-proxy.jar
Each component (or module represented here by jar files) could belong to
a separate build, that depends on other components.
The qa-platform would itself be another build, and the tests relevant to
each component would be part of that component, for fast test driven
development.
The minimum requirement for a client would be:
Java 1.5
jini-platform.jar
jini-policy.jar
jini-resources.jar
river-impl.jar
and at least one or more *service-api.jar
If a service download requires another service (which the client doesn't
directly depend) the service proxy can include these files in it's
codebase annotations.
Cheers,
Peter.
Mike wrote:
On 23/10/2010 12:39, Peter Firmstone wrote:
Mike, are you interested in helping?
Yes I am. Unfortunately it won't be very soon - I am off on business for
the next couple of weeks. Additionally I would be interested to see more
discussion on how the codebase should be partitioned than my poor stab
at it.
It isn't going to be easy, but we need to do it, since it enables more
people to work on different distinct components and will reduce the test
duration. It takes a whole day to run the tests, not much help for tdd.
Hadn't even thought about that! Good catch.
