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

Reply via email to