New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modularization or Automatic-Module-Name #374

Closed
io7m opened this Issue Dec 8, 2017 · 6 comments

Comments

Projects
None yet
2 participants
@io7m
Copy link

io7m commented Dec 8, 2017

Hello!

The rome project already appears to be quite modular. Is there any intention to publish full JDK 9 modules? Failing that, is there any chance a new release could be pushed with
Automatic-Module-Name entries in the jar manifests?

@io7m io7m referenced this issue Dec 8, 2017

Open

Modularize #12

@mishako

This comment has been minimized.

Copy link
Member

mishako commented Dec 10, 2017

Hi Mark! I see that you're helping other teams with jdk9 modules. Very nice! Any chance you can help us too? We are already publishing OSGi bundles (see #216). I guess jdk9 modules are similar? If you're busy it's fine, we can probably figure it out.

@io7m

This comment has been minimized.

Copy link
Author

io7m commented Dec 10, 2017

Hello. Yes, I can certainly help. As you're already publishing OSGi bundles, you've likely already done the hard work (knowing what packages you need to export, avoiding circular dependencies, etc).

I see from your main parent POM that you're producing JDK 6 bytecode. If you want to go the full modularization route, the least painful way to proceed is to start requiring JDK 9 to build the code. You'll still be only requiring JDK 6 to run the code, but anyone building from source would require JDK 9 to do so. JDK 9 has some nice features that give stronger guarantees about compatibility than previous JDK releases did. For example, if you compile the code with JDK 8, specifying Java 6 bytecode as the output, nothing actually stops you from accidentally using JDK 8 APIs. The new -release flag in JDK 9 enforces API usage too, so it's a compelling reason to move to the new version.

Depending on how you feel about using JDK 9, I can make an initial pass over the codebase to write the initial module descriptors and the required maven-compiler-plugin executions. The main thing that can block the work is if you depend on libraries that haven't yet been modularized (or that haven't published Automatic-Module-Name entries). I've not checked these yet.

@mishako

This comment has been minimized.

Copy link
Member

mishako commented Dec 17, 2017

Yeah, looks like the libraries we depend on (slf4j and jdom2) don't declare Automatic-Module-Name in their jars. I created a pull-request for our jars (#375), but I'm guessing our dependencies need to be updated too in order for anyone to use Rome in a modular environment.

@io7m

This comment has been minimized.

Copy link
Author

io7m commented Dec 17, 2017

I don't know about jdom2, but the beta version of the 1.8.0 slf4j API does have the right entries (both logback and log4j appear to be fully modularized right now).

@io7m

This comment has been minimized.

Copy link
Author

io7m commented Feb 26, 2018

I wrote a small Maven plugin that can give you a reasonable idea as to what needs to be done in order to modularize your projects:

https://github.com/io7m/modulechaser

The results for rome aren't all that enlightening (they're what we've already discussed: slf4j and logback are modularized, jdom2 isn't in any form).

@mishako

This comment has been minimized.

Copy link
Member

mishako commented Jul 6, 2018

Closing this because Rome has Automatic-Module-Name since version 1.10.0 (pull request #375).

@mishako mishako closed this Jul 6, 2018

@mishako mishako added this to the 1.10.0 milestone Jul 6, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment