Kathey Marsden wrote:
Jeremy Boynes wrote:
Currently we have:
* derby.jar (embedded, engine)
* derbynet.jar (network server)
* derbyclient.jar (network client)
I would like to add derbyserver.jar which includes everything from all
of these to form a complete standalone server; the client is included
so that people don't need to switch classpath if they want to use a
remote server and so that stored procedures can access remote servers.
If we do this was can also potentially drop derbynet.jar as it is not
usable without derby.jar.
Any objections?
-
This looks good to me at first glance. derbynet.jar needs to stick
around for a bit anyway as it is the only thing documented and we would
need to deprecate it properly.
Does this mean ,,,
* The unified datasource is just available if you use derbyserver.
No, I would include it in all for consistency. The usage model for each
package would be:
derbyserver.jar - general purpose, client, server and embedded
derbyclient.jar - thin client only
derby.jar - embedded only
derbynet.jar - deprecated, adds server mode to embedded
* The other datasources stick around for the long term.
Dan wants to go Darwinian on which ones stuck around - release all now
and see which ones people use.
--
Jeremy
