Build as Java 9 modules

[metacodez]

It would help other Java 9 modules and their module-info.java declaration to put an entry into the JAR's Manifest-File, such as: Automatic-Module-Name: org.jline.terminal to get stable module references. In Maven, this can be achieved by tweaking the maven-jar-plugin similar to:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <configuration>
        <archive>
            ...
            <manifestEntries>
                <Automatic-Module-Name>org.jline.terminal</Automatic-Module-Name>
            </manifestEntries>
        </archive>
    </configuration>
    ...
</plugin>

[gnodet]

I have an old branch I started earlier: https://github.com/jline/jline3/tree/wip-jigsaw I'm not really keen on integrating those changes with all the repackaged dependencies, I'd rather wait until the dependencies have their own metadata. That said, if you want to provide a PR with the automatic module names, I'd happily merge it.

[Thihup]

Would now be possible to add the module-info to the project? There are two ways: requiring a JDK 9+ to build the project and adding the module-info.java or using a tool like Moditect to generate the module-info and use JDK 8 to build.

[ice1000]

It would be very nice if this can natively support jpms, so downstream projects can use jlink.

[bowbahdoe]

Bumping. Downstream dependencies like https://github.com/ctongfei/progressbar still need a module-info from this in order to be usable with jlink

[gnodet]

Bumping. Downstream dependencies like https://github.com/ctongfei/progressbar still need a module-info from this in order to be usable with jlink

Do you think you could rais a PR for that ?

[bowbahdoe]

@gnodet I looked into adding module descriptors (first by locally bumping to java 9 and adding them and translating to moditect after), but I ran into a few issues

1. There are optional dependencies like jansi which are not themselves modularized (the whole tree needs to be modularized for people to not get hit with an error).

I started on that work a bit, https://github.com/fusesource/jansi/pull/254.

2. What to do about the "uberjar" that is org.jline/jline with regard to the submodules which are available separately?

https://mvnrepository.com/artifact/org.jline/jline

[bowbahdoe]

And I suppose also

3. I'm not sure if I'm aware of all the service provider usages. (those go in the module-info too)

[gnodet]

@gnodet I looked into adding module descriptors (first by locally bumping to java 9 and adding them and translating to moditect after), but I ran into a few issues

1. There are optional dependencies like jansi which are not themselves modularized (the whole tree needs to be modularized for people to not get hit with an error).

I started on that work a bit, fusesource/jansi#254.

Yes, that's the problem, all dependencies have to be modularized... I'll have a look at your PR.

2. What to do about the "uberjar" that is org.jline/jline with regard to the submodules which are available separately?

I think we need to ignore that one. If people want to use java modules, they'll have to use the thiner jars.

For services, the TerminalProvider is obviously the main one. Implementations are provided by jline-terminal, jline-terminal-jna and jline-terminal-jansi.