Closed jkuhn1 closed 2 years ago
Thanks for the patch. I did a bit of reading on the module system and it's not clear to me whether org.ldaptive.core
or org.ldaptive
is more appropriate. I guess I'm leaning towards the latter.
Well this is similar as to name a Maven artifact since a Java module has a similar semantic. My rule of thumb is to name module after the artifact (group id + artifact id). In this particular case, I looked at the Maven project structure, see core/
, hence org.ldaptive.core
but you're right I didn't notice that the artifact ID is actually not core
but ldaptive
so org.ldaptive
might do after all. The only thing to keep in mind is that it has to be unique.
Another important thing to know regarding Java module system, when actually defining a module-info.java
(automatic modules are exceptions made for compatibility: all packages are exported and this rule is not applied), is the fact that two modules can't export the same package. For example, if you consider modules org.ldaptive
and org.ldaptive.beans
only one can export (i.e. make its classes available to other modules) package org.ldaptive
. It basically forces you to be clear on what a module provides.
Closed in favor of https://github.com/vt-middleware/ldaptive/commit/4ef6d2eb3b337e593e489ed3f01a4d4fb7478ea7 I riffed on this patch a little bit, but ultimately went with a properties based solution.
Fix #212
I've updated the
pom.xml
to add theAutomatic-Module-Name
attribute in theMANIFEST.MF
filesWe should now have the following Java automatic modules:
org.ldaptive.beans
org.ldaptive.core
org.ldaptive.json
org.ldaptive.templates