[
https://issues.apache.org/jira/browse/DERBY-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16294226#comment-16294226
]
Rick Hillegas commented on DERBY-6945:
--------------------------------------
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)
