Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Fri, 29 Dec 2017 19:29:00 +0000 (UTC)
From: "Rick Hillegas (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.13084066.1499013566000.547702.1514575740253@Atlassian.JIRA>
In-Reply-To: <JIRA.13084066.1499013566000@Atlassian.JIRA>
References: <JIRA.13084066.1499013566000@Atlassian.JIRA> <JIRA.13084066.1499013566439@jira-lw-us.apache.org>
Subject: [jira] [Commented] (DERBY-6945) Re-package Derby as a collection of
 jigsaw modules
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Fri, 29 Dec 2017 19:29:04 -0000


    [ 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)