[
https://issues.apache.org/jira/browse/DERBY-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16307642#comment-16307642
]
Rick Hillegas commented on DERBY-6945:
--------------------------------------
I'm proposing to move the AutoloadedDriver class out of org.apache.derby.jdbc
and into another package which lives in derby.jar. Let's say that the new
location will be org.apache.derby.engine.jdbc.AutoloadedDriver.
AutoloadedDriver is the driver which is named in the
META-INF/services/java.sql.Driver file in derby.jar. Happily, it is not part of
the public api. I'm proposing that the contents of derby.jar's
META-INF/services.java.sql.Driver would be the following line:
org.apache.derby.engine.AutotloadedDriver
Right now the EmbeddedDriver forwards all of its methods to AutoloadedDriver.
That wouldn't change. Only the location of AutoloadedDriver would change.
A similar trick would have to be done for the ClientDriver. Right now it is
what's referenced in the META-INF/services/java.sql.Driver file of
derbyclient.jar. I'm proposing that CientDriver would forward its methods to,
say,
org.apache.derby.client.AutoloadedClientDriver and that the contents of
derbyclient.jar's META-INF/services/java.sql.Driver file would be the following
line:
org.apache.derby.client.AutoloadedClientDriver
The driver implementations mentioned in the META-INF/services/java.sql.Driver
files are what the JVM loads when an application calls
DriverManager.getConnection() for the first time.
There are two ways to get a connection: call DriverManger.getConnection() or
call the getConnection() method of a DataSource. The first way will work
without any DataSources on the classpath, so it won't need any of the public
api classes in org.apache.derby.jdbc.
Does that make sense or have I made the situation even more confusing?
Thanks.
> Re-package Derby as a collection of jigsaw modules
> --------------------------------------------------
>
> Key: DERBY-6945
> URL: https://issues.apache.org/jira/browse/DERBY-6945
> Project: Derby
> Issue Type: Improvement
> Affects Versions: 10.13.1.2
> Reporter: Rick Hillegas
> Attachments: derby-6945-01-aa-remove_derbyPreBuild_dep.diff,
> derby-6945-02-ab-newDerbySharedJar.diff,
> derby-6945-02-ac-newDerbySharedJar.diff, derby-6945-03-aa-partitionTest.diff,
> derby-6945-04-aa-moveRunClass.diff,
> derby-6945-05-aa-removeRedundant_Attribute_SQLState.diff,
> derby-6945-06-aa-removeOtherSharedDuplicates.diff,
> derby-6945-07-aa-net_client_overlap.diff,
> derby-6945-08-aa-move_shared_iapi_under_shared.diff,
> derby-6945-08-ab-move_shared_iapi_under_shared.diff,
> derby-6945-08-ad-move_shared_iapi_under_shared.diff, jdeps.out.tar
>
>
> Once we commit to building with Java 9 (see DERBY-6856), we should consider
> re-packaging Derby as a set of jigsaw modules. This would result in a
> different set of release artifacts. This might be a good opportunity to
> address the Tomcat artifactory issues raised by issue DERBY-6944.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
