[
https://issues.apache.org/jira/browse/DERBY-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303348#comment-16303348
]
Rick Hillegas commented on DERBY-6945:
--------------------------------------
Yet another variation on 2:
2'') As in 2', separate out org.apache.derby.jdbc and use reflection to break
the compile-time linkages to derby.jar and derbyshared.jar. Put the isolated
org.apache.derby.jdbc classes in a new micro-module called
org.apache.derby.jdbc. On the one hand, I am reluctant to create tiny module
splinters like this. On the other hand, this approach would break the engine
and client's compile-time dependency on the java.naming module. Applications
which get a Connection via DriverManager.getConnection() would not need to
reference the org.apache.derby.jdbc classes and therefore they would not
fault-in the 444K weight of the java.naming module.
> 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, 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)
