[
https://issues.apache.org/jira/browse/DERBY-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802287#comment-16802287
]
Rick Hillegas commented on DERBY-7039:
--------------------------------------
You are right, the DataSources moved up into the tools jar in order to preserve
the backward compatibility of the Derby public API and to achieve the package
partitioning required by JPMS. This move was discussed on DERBY-6945 beginning
on 2017-12-28.
The tools module does NOT have a hard dependency on either the engine or the
client jars. I see that this may not be obvious simply from studying the module
diagram at
https://db.apache.org/derby/docs/10.15/publishedapi/org.apache.derby.tools/module-summary.html.
That diagram follows the coloring conventions described at
http://db.apache.org/derby/docs/10.15/publishedapi/index.html:
light-gray-colored modules are optional dependencies. Blue- and black-colored
modules are hard dependencies.
You do NOT need the client jar in order to run Derby embedded. You only need
the following:
* The engine jar (derby.jar)
* The shared jar (derbyshared.jar)
If you want to access Derby via the embedded DataSources, you only need one
additional jar file:
* The tools jar (derbytools.jar).
That, at least, is how things are supposed to work. Have you discovered a
coupling between the engine and client jars which prevents you from running
your application with just derby.jar, derbyshared.jar, and derbytools.jar?
Thanks,
-Rick
> DataSource classes removed from derby.jar
> -----------------------------------------
>
> Key: DERBY-7039
> URL: https://issues.apache.org/jira/browse/DERBY-7039
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.15.1.3
> Reporter: Andy Guibert
> Priority: Major
>
> Between versions 10.14.X and 10.15.X the DataSource implementation classes
> under the org.apache.derby.jdbc package were removed from the derby.jar. It
> looks like the DataSource classes were moved to derbytools.jar, which has a
> dependency on the derbynetwork.jar:
> [https://db.apache.org/derby/docs/10.15/publishedapi/org.apache.derby.tools/module-summary.html]
> This makes it impossible to use just a Derby Embedded DataSource, without
> pulling in all of the Derby Network Client code too.
> It appears this change was made for the sake of modularity, since split
> packages are not allowed in JPMS modules, and the org.apache.derby.jdbc
> package contains DataSource classes for both Embedded and Network usage. I am
> not sure what the best way to untangle this dependency issue is, but ideally
> it can be done in a way that doesn't require dependencies on Derby Embedded
> and Network clients in order to use DataSource at all.
> One possible suggestion is to introduce new DataSource classes in new
> packages, such as:
> org.apache.derby.jdbc.embedded // for Embedded DataSource classes
> org.apache.derby.jdbc.network // for Network Client DataSources
> Then, gut out the DataSource classes in org.apache.derby.jdbc and have them
> extend from their respective embedded/network implementations. This will
> allow existing users to add more dependencies and leave their code unchanged,
> or it will allow users who just want to depend on Embedded or Network clients
> to update the DataSource class name.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
