db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6945) Re-package Derby as a collection of jigsaw modules
Date Fri, 29 Dec 2017 19:29:00 GMT

    [ 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:
>            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,
> 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

This message was sent by Atlassian JIRA

View raw message