Declare stable Java module name

Currently this library does not define a stable Java module name. Thus this automatic module name is derived from it’s JAR filename to be ical4j.

It would be useful to set a stable automatic module name to what it will eventually be when the library natively supports the JPMS (see #345). net.fortuna.ical4j is one possibility but would take ownership of the package of the same name. This would conflict with other projects being subpackages thereof (e.g. net.fortuna.ical4j.vcard).

Maybe the best solution would be moving the net.fortuna.ical4j package from this project to net.fortuna.ical4j.core with the next big version. That way the module name net.fortuna.ical4j.core would not conflict with the other projects.

For more details about Java module names see: sormuras/modules#about-java-module-names

[benfortuna]

Yeah, I guess I’m just looking for some precedent for how other libraries similar to ical4j have done it.

For example, if I look at slf4j I can see they didn’t change the core package (although the “sub modules” don’t appear to export packages explicitly, but they do provide services in the same namespace):

module org.slf4j { 
  exports org.slf4j;
  exports org.slf4j.spi;
  exports org.slf4j.event;
  exports org.slf4j.helpers;
  uses org.slf4j.spi.SLF4JServiceProvider;
}

https://github.com/qos-ch/slf4j/blob/master/slf4j-api/src/main/java9/module-info.java

module org.slf4j.nop { 
  requires org.slf4j;
  provides org.slf4j.spi.SLF4JServiceProvider with org.slf4j.nop.NOPServiceProvider;
}

https://github.com/qos-ch/slf4j/blob/master/slf4j-nop/src/main/java9/module-info.java

Log4j also hasn’t changed the base package but then I can only see one module from that project:

module org.apache.logging.log4j {
    exports org.apache.logging.log4j;
    exports org.apache.logging.log4j.message;
    exports org.apache.logging.log4j.simple;
    exports org.apache.logging.log4j.spi;
    exports org.apache.logging.log4j.status;
    exports org.apache.logging.log4j.util;

    uses org.apache.logging.log4j.spi.Provider;
    uses org.apache.logging.log4j.util.PropertySource;
    uses org.apache.logging.log4j.message.ThreadDumpMessage.ThreadInfoFactory;
}

https://github.com/apache/logging-log4j2/blob/master/log4j-api-java9/src/main/java/module-info.java

I’ll keep looking for better examples, but my current thinking is that it doesn’t feel right to change the base package of ical4j (i.e. org.mnode.ical4j.core.*), but if necessary perhaps the other libraries will require a more significant package name change I’m still in the process of understanding the new module system. 😉

Trying to think in a modular way (and potential for library split in the future) it does probably make sense to use a core base package for all the exported classes, I think we need to understand what those exported classes would be (i.e. the whole library or a subset?)

I want to explore all the possibilities as in the articles linked above they say to think very carefully about the module/package naming.

[benfortuna]

Updated ical4j-integration, will be released shortly.