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


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

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

Yes that helps.

I was confused about whether derbytools.jar needed to be in the classpath or not.

I take your answer to mean: "if we always auto-load the drivers (both client driver and embedded driver), then the auto-loaded drivers are never referenced by their explicit class names, so we can keep them located in separate jar files (derby.jar, derbyclient.jar); therefore a carefully written application which only uses the JDBC Connection URL to specify which driver to load, need not ever explicitly mention a JDBC driver class name, and hence can run without needing derbytools.jar in the CLASSPATH."

Am I in sync with your idea?

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