[
https://issues.apache.org/jira/browse/DERBY-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306480#comment-16306480
]
Rick Hillegas commented on DERBY-6945:
--------------------------------------
Thanks for that suggestion, Martin. I had not considered the solution which you
are proposing. I believe that the developer experience would be as follows:
L1) Legacy applications would run on Derby 10.15 and also on earlier versions
of Derby.
L2) However, when compiling an old application against the Derby 10.15 jars,
the developer would see deprecation warnings. The developer would be encouraged
to use new classes in the public api.
I think this change would entail the following community interaction:
C1) Call a vote to approve the change to the public api. The change would be
phased in over two releases. In 10.15, the old api would still work but
deprecation warnings would appear during compilation of legacy applications.
C2) In 10.16, the old classes would be removed. By then, legacy applications
should have changed their import statements.
I don't have a lot of visibility into usage of the client driver vs. the
embedded driver. Many years ago, a survey taken at Java One suggested that 40%
of Derby usage involved the client driver and 60% involved the embedded driver.
If we were to adopt this approach, then my preference would be to leave the
embedded DataSources and driver in org.apache.derby.jdbc and re-locate the
client DataSources and driver to a new package in client.jar.
> 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)
