[ https://issues.apache.org/jira/browse/DERBY-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16294226#comment-16294226 ]
Rick Hillegas edited comment on DERBY-6945 at 12/17/17 4:55 PM: ---------------------------------------------------------------- h2. Module Names I would like to start a discussion about module names now, informed by Alex Buckley's advice, [Mark Reinhold's Jigsaw overview](http://openjdk.java.net/projects/jigsaw/spec/sotms/), and [Stephen Colebourne's blog](http://openjdk.java.net/projects/jigsaw/spec/sotms/). I am only ready to discuss the names of top level modules, that is, the ones which correspond to Derby jar files. Undoubtedly, top level modules will have sub-modules. I am cautiously hopeful that sub-module names will be straightforward once we name the top ones. Mark Reinhold's examples and Stephen Colbourne's advice agree that module names should start with the reverse-DNS specification of our package space: org.apache.derby. That should insulate us from name conflicts with other projects and products. In the unlikely event of a conflict, the ASF is in a strong position to defend our claim to this namespace. Here are a number of ideas about what we should call the top-level modules. 1. Named after the jar files We could simply add the jar file name to the end of the project prefix: org.apache.derby.derby org.apache.derby.derbyclient org.apache.derby.derbynet org.apache.derby.derbyoptionaltools org.apache.derby.derbyrun org.apache.derby.derbyshared org.apache.derby.derbytools 2. Named after top-level directories Alternatively, we could name the modules after the top level branches of the source tree (that is, the subdirectories of trunk/java). Note that I am planning to add a new subdirectory to hold the package for derbyrun's entry point (trunk/java/tools/org/apache/derby/iapi/tools/run.java). I am tentatively thinking of naming it simply "run": org.apache.derby.engine org.apache.derby.client org.apache.derby.drda org.apache.derby.optional org.apache.derby.run org.apache.derby.shared org.apache.derby.tools 3. Named more descriptively Alternatively, we could follow Alex Buckley's advice and come up with more descriptive handles: org.apache.derby.rdbms org.apache.derby.remote_jdbc_client org.apache.derby.network_server org.apache.derby.plugins org.apache.derby.programs org.apache.derby.common org.apache.derby.core_tools There are, of course, many variations on the third option. What are your thoughts? was (Author: rhillegas): h2. Module Names I would like to start a discussion about module names now, informed by Alex Buckley's advice, [http://openjdk.java.net/projects/jigsaw/spec/sotms/|Mark Reinhold's Jigsaw overview], and [http://openjdk.java.net/projects/jigsaw/spec/sotms/|Stephen Colebourne's blog]. I am only ready to discuss the names of top level modules, that is, the ones which correspond to Derby jar files. Undoubtedly, top level modules will have sub-modules. I am cautiously hopeful that sub-module names will be straightforward once we name the top ones. Mark Reinhold's examples and Stephen Colbourne's advice agree that module names should start with the reverse-DNS specification of our package space: org.apache.derby. That should insulate us from name conflicts with other projects and products. In the unlikely event of a conflict, the ASF is in a strong position to defend our claim to this namespace. Here are a number of ideas about what we should call the top-level modules. 1. Named after the jar files We could simply add the jar file name to the end of the project prefix: org.apache.derby.derby org.apache.derby.derbyclient org.apache.derby.derbynet org.apache.derby.derbyoptionaltools org.apache.derby.derbyrun org.apache.derby.derbyshared org.apache.derby.derbytools 2. Named after top-level directories Alternatively, we could name the modules after the top level branches of the source tree (that is, the subdirectories of trunk/java). Note that I am planning to add a new subdirectory to hold the package for derbyrun's entry point (trunk/java/tools/org/apache/derby/iapi/tools/run.java). I am tentatively thinking of naming it simply "run": org.apache.derby.engine org.apache.derby.client org.apache.derby.drda org.apache.derby.optional org.apache.derby.run org.apache.derby.shared org.apache.derby.tools 3. Named more descriptively Alternatively, we could follow Alex Buckley's advice and come up with more descriptive handles: org.apache.derby.rdbms org.apache.derby.remote_jdbc_client org.apache.derby.network_server org.apache.derby.plugins org.apache.derby.programs org.apache.derby.common org.apache.derby.core_tools There are, of course, many variations on the third option. What are your thoughts? > 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, 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)