"If it would be easier for people to work with river" That will depend on what you mean by the runtime classes. If you mean to include the -dl.jars of various services it likely won't be easier as including what should be downloaded proxy code in the classpath can result in ClassCastExceptions and such which are hard to debug and difficult to understand. Further it can compromise the ability to manage multiple versions of services.
For a user just getting started, it may be no big deal but as they progress, becoming more sophisticated they'll be bitten by the defaults they're used to. So if a river.jar as you describe is what people want to do, I would suggest some documentation is in order. On 31 December 2010 17:11, Sim IJskes - QCG <s...@qcg.nl> wrote: > On 31-12-10 17:18, tras...@trasuk.com wrote: > >> Isn't that already jsk-platform.jar? I would object to anything that >> subverts the dynamic proxy loading concept that is central to Jini. >> >> It is imperative that people don't, for instance, get the >> service-registrar proxy impls in their local class path. That would >> break compatibility with future or alternate impls. >> > > If it would be easier for people to work with river, why would we be > against it. It is about offering people options, not about forcing people to > use a certain concept. I do think to use the word 'subverting' is indicating > a strong tendency to force people to use a certain piece of software in the > way you think they should. I think this is way too directive. > > Gr. Sim >
