JDK9+ Incorrect JPMS Automatic-Module-Name = simple-java-mail

[colesico]

Jpms module name Automatic-Module-Name: simple-java-mail in MANIFEST.MF is not valid, change it please to simple.java.mail or else that is valid. thx!

[triceo]

This is a critical problem that prevents simple-java-mail library from being included in modularized application. PR coming.

[triceo]

Actually, scratch that. In order for me to be able to add correct automatic module infos, I would have to:

• Make the project compile on Java 11. (I don't use Java 8 anymore.)
• For that, I have to work around the nonnull plugin which is so outdated it can not deal with Java 11 classfiles.
• For that, I have to reconfigure maven-compiler-plugin to consistently only build Java 7-compatible class files.
• And I failed to do that, since pluginManagement does not override the maven-compiler-plugin 3.5.1 coming from some parent POM outside of this Github repo.

At this point, I decided I don't have enough time to follow the rabbit hole so deep. :-) commons-email it is.

[bbottema]

Actually, scratch that. In order for me to be able to add correct automatic module infos, I would have to:
(..)

Hmm, sounds like shaving a yak :D

Ok, so I control the parent POM repo's, does that help? I have some time now to take care of things.

If the nonnull really can't work with Java 11, I think it should be tossed out until something better comes along. However, you can already simply disable the plugin:

Simply add the following property to the POM:

<se.eris.notnull.instrument>false</se.eris.notnull.instrument>

That should greatly simplify the problem, yes?

[triceo]

Ok, so I control the parent POM repo's, does that help? I have some time now to take care of things.

I think that it would help if the plugin configurations in those outside POMs moved to pluginManagement section - that would allow overrides later.

If the nonnull really can't work with Java 11, I think it should be tossed out until something better comes along.

I agree. I checked, there is no newer version.

<se.eris.notnull.instrument>false</se.eris.notnull.instrument>

That should greatly simplify the problem, yes?

Disabling it would help, yes. If that's allowed, I may give it another try later.

[bbottema]

Yes, let's disable it for now.

Sounds like the Java 11+ multi-release issue has become more important now as well.

[triceo]

@bbottema This is actually a precursor to #237.
You can have your library running in a modular system on Java 11, with the correct automatic module names. (This is what this issue is about.)
#237 is about making it possible to have the library be a full-fledged Java module. It's not necessary, but not doing it prevents people from using jlink.

[bbottema]

Ahh, ok. Seems like the next step for Simple Java Mail then is to be more compatible with the future and get both these issues out of the way.

[triceo]

I have attached a Patch with limited Java 11 support.

However, it only works like this:

mvn clean install -Djacoco.skip=true -DskipTests

For full support:

• JaCoCo needs updating in one of the outside POMs.
• org.simplejavamail.converter.internal.mimemessage.MimeMessageHelperTest will need rewriting. It uses reflection on JDK internals, which I believe is illegal now.

To make any sort of changes easier in the future, I also suggest refactoring the POMs so that the outside POMs don't have absolute control. Case in point: maven-compiler-plugin. I didn't figure out a way to upgrade its version (or Surefire, JaCoCo, ...) without touching the outside POMs.