[
https://issues.apache.org/jira/browse/DERBY-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16305660#comment-16305660
]
Martin Desruisseaux commented on DERBY-6945:
--------------------------------------------
What about the following alternative? (sorry if you already considered it):
* Move one of the set of classes (either the client or the server one) to a
different package, for allowing distinct modules.
* Deprecate the old classes that moved.
* Modify implementation of deprecated classes so that they delegate all their
method calls to the non-deprecated classes with reflection.
I realize that this break the strict backward compatibility rule, but the
deprecated classes can be kept around an undetermined amount of time. Users who
can afford modifying their code would have a clean model.
> 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, 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)
