Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Mon, 1 Jan 2018 17:17:00 +0000 (UTC)
From: "Bryan Pendleton (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.13084066.1499013566000.552919.1514827020155@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: Mon, 01 Jan 2018 17:17:05 -0000


    [ https://issues.apache.org/jira/browse/DERBY-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16307500#comment-16307500 ] 

Bryan Pendleton commented on DERBY-6945:
----------------------------------------

I like the idea of putting the external JDBC driver classes into derbytools.jar; it makes sense to me to think of derbytools.jar as "the jar file where all the external classes that you directly reference live". That is, things like sysinfo, ij, etc. are all just "entry points" into the Derby functionality, which is also true of the client and embedded drivers.

But I think you went over that idea a bit too fast for me, at least your item (1) is confusing to me.

If the JDBC Driver classes are in derbytools.jar, how does an application invoke a JDBC driver using just derby.jar+derbyshared.jar or just derbyclient.jar+derbyshared.jar? Is one of those jars automatically pulling derbytools.jar into the classpath somehow?


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