vt-middleware / ldaptive

A simple, extensible Java API for interacting with LDAP servers
56 stars 26 forks source link

Set Automatic-Module-Name attributes in MANIFEST.MF #213

Closed jkuhn1 closed 2 years ago

jkuhn1 commented 2 years ago

Fix #212

I've updated the pom.xml to add the Automatic-Module-Name attribute in the MANIFEST.MF files

We should now have the following Java automatic modules:

dfish3r commented 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.

jkuhn1 commented 2 years ago

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.

dfish3r commented 2 years ago

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.