[
https://issues.apache.org/jira/browse/DERBY-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802877#comment-16802877
]
Rick Hillegas commented on DERBY-7039:
--------------------------------------
Thanks for raising the issue with the maven poms. I have opened DERBY-7040 to
track the work of aligning Derby's maven dependency descriptors with the hard
dependencies in the module diagrams. Note, however, that this will not address
your issue with applications failing to build against 10.15.1.3 because the
DataSources moved into the tools jar. If your application uses DataSources,
then it should explicitly depend on the tools jar.
There is another reason for moving the embedded DataSource out of the engine
jar: The DataSource api depends on the java.naming module. In the interests of
keeping the smallest (embedded) configuration as lean as possible, we did not
want to create a dependency between the engine module and java.naming. Via the
java.sql.DriverManager api, it should be possible to run Derby on a
resource-constrained device without pulling in java.naming.
> 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)
