Packaging

[Jeremy Boynes <jb...@apache.org>]

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?
--
Jeremy

Re: Packaging

[David Van Couvering <Da...@Sun.COM>]

Hm, OK, fair enough.  I'm not sure if this applies to the work you're 
doing, but there is another aspect to this: right now the package 
hierarchy doesn't make it clear where common code goes -- there should 
be a specific package, org.apache.derby.common or something like that.

David

Jeremy Boynes wrote:
> David Van Couvering wrote:
> 
>> You might want to take a look at DERBY-289 ("enable code sharing 
>> between Derby client and engine").  Any rearrangement of jar files 
>> should probably take this into consideration.
> 
> 
> With the desire to have a single entry on the classpath, I was planning 
> on including the common code in all jars where it was needed.
> 
> -- 
> Jeremy

Re: Packaging

[Jeremy Boynes <jb...@apache.org>]

David Van Couvering wrote:
> You might want to take a look at DERBY-289 ("enable code sharing between 
> Derby client and engine").  Any rearrangement of jar files should 
> probably take this into consideration.

With the desire to have a single entry on the classpath, I was planning 
on including the common code in all jars where it was needed.

--
Jeremy

Re: Packaging

[David Van Couvering <Da...@Sun.COM>]

You might want to take a look at DERBY-289 ("enable code sharing between 
Derby client and engine").  Any rearrangement of jar files should 
probably take this into consideration.

David

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?
> -- 
> Jeremy
> 

Re: Packaging

[Daniel John Debrunner <dj...@debrunners.com>]

Jeremy Boynes wrote:
> 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.

Are we saying that there is no need for anyone to ship embedded +
network server only, as can be done today (derbynet + derby)?
I'd hate to see that option go away.

It's an interesting issue, does the Derby project provide just the base
technologies in jar files, as is done today, and let users assemble
combinations, or does Derby provide typical (if not all) combinations?

Dan.

Re: Packaging

[Jeremy Boynes <jb...@apache.org>]

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

Re: Packaging

[Kathey Marsden <km...@sbcglobal.net>]

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.
  *  The other datasources stick  around for the long term.

?

Kathey