db-derby-dev mailing list archives

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

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

Stephen Colebourne commented on DERBY-6945:

Some points:

* Each jar file that can be a dependency must have a single module name
* Each package must be in a single module
* Thus, each package must be in a single jar file
* There is no requirement to have the module name equal the super-package name, it is just
more convenient in most cases
* Uber-jar files (jar-with-dependencies) should not have a module name

If you can't establish anything better, just naming the modules `org.apache.derby.<jarfilename>`
will work, providing that no package is in two modules.

Taking a very brief look at `derby.jar ` and `derbyclient.jar `, they both contain the same
package. As such, they cannot both be on the module-path at the same time. `derbynet.jar`
also shares 3 packages. As such, Derby is not currently viable to be used with the Java module
system - it will need surgery between the jar files to ensure that no package is in two jar
files (where a user might want both on the module-path).

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