Feel free to add.
Option 1, minimum java version for everything:
Advantages:
* Don't need a modular build.
* Less work now.
Disadvantages:
* Implementations restricted to minimum platform features.
* Earlier or different platform deployed clients cannot utilise services in
a mixed environment.
Option 2, define modules now:
My suggestion:
Two required for each service implementation, server and proxy:
* Reggie
* Mahalo
* Outrigger
* Phoenix
* Mercury
* Fiddler
* Norm
The platform:
* A minimum required Jini platform module.
* Service api module.
* A private implementation library module.
* Policy extensions module.
Then consider each on its individual merits and needs.
Option 3, exemption for a single undisputed subsystem:
If we're experiencing difficulties arriving at a decision, a new outrigger
utilising concurrency libraries can be a separate implementation of the
existing javaspaces service api and use any java features necessary (just
quietly, I think this'll be a huge improvement over the current buggy
implementation). The same goes for any other service implementation.
There's also a separate experiment to utilise generics in javaspace.
Modularity appears to satisfy everyones needs, without sacrificing
compatibility with earlier or alternate java platforms. (Don't worry Mike, we
can have rtsj service implementations if you really need them, these can be
based on existing implementations) I experimented recently, it wasn't that hard
to break it up into components, I used ant, because I don't have any maven
experience, but this should wait until after the river namspace changes, which
should happen after the 2.1.3 release.
Cheers,
Peter.
