[
https://issues.apache.org/jira/browse/DERBY-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802438#comment-16802438
]
Andy Guibert commented on DERBY-7039:
-------------------------------------
Hi Rick, thanks for clarifying the optional vs. required dependencies.
The issue I ran into was that I simply updated my org.apache.derby:derby
dependency to the latest version in Maven Central, and found that the
DataSource classes were gone. I think at the very least the maven dependencies
should be set up such that if you depend on org.apache.derby:derby:10.15.1.3
then you also get derbyshared.jar and derbytools.jar via transitive
dependencies. Currently I get neither of these from the Maven dependency.
However, it doesn't really make sense why the DataSource and Driver classes are
in the derbytools module. I would expect the embedded DS/Driver classes and the
network DS/Driver classes in the derby and derbynetwork jars respectively. It
looks like the only reason why these DS classes are in the derbytools.jar is to
avoid a split package issue with JPMS? If yes, I think we can work out some
alternate solutions.
> 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)
