Skip to content
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

Any chance you could add an Automatic-Module-Name? #1128

Closed
io7m opened this issue Apr 19, 2020 · 6 comments · Fixed by #1129
Closed

Any chance you could add an Automatic-Module-Name? #1128

io7m opened this issue Apr 19, 2020 · 6 comments · Fixed by #1129
Assignees
Labels
priority: medium To be processed and published in one of the upcoming releases status: completed Work completed, can be closed type: feature The issue describes a new feature request
Milestone

Comments

@io7m
Copy link
Contributor

io7m commented Apr 19, 2020

Hello!

Any chance you could add an Automatic-Module-Name manifest entry? I'd suggest org.w3c.epubcheck.

See the following for details: http://branchandbound.net/blog/java/2017/12/automatic-module-name/

io7m added a commit to io7m/epubcheck that referenced this issue Apr 19, 2020
This adds an Automatic-Module-Name manifest entry in order to allow
epubcheck to be used in a modular context without having to depend
on an unstable generated module name.

Fix: w3c#1128
@io7m
Copy link
Contributor Author

io7m commented Apr 19, 2020

PR here: #1129

@rdeltour
Copy link
Member

Thanks for the issue and the PR 👍

I’m not familiar with the Java 9 module system, so I’ll have to dig into it first (thanks for the pointer 😊), but the request sounds reasonable at first sight!

@rdeltour rdeltour self-assigned this Apr 21, 2020
@rdeltour rdeltour added priority: medium To be processed and published in one of the upcoming releases status: needs review Needs to be reviewed by a team member before further processing type: feature The issue describes a new feature request labels Apr 21, 2020
@rdeltour rdeltour added this to the 4.2.3 milestone Apr 21, 2020
@io7m
Copy link
Contributor Author

io7m commented Apr 21, 2020

Thanks!

What this basically comes down to is that if your jar file doesn't contain a module descriptor (an explicit module-info.class file containing lists of required modules and exported packages), the module system will essentially try to infer one for you. It'll use the name of the jar file as the module name (epubcheck in your case) and it'll pretend that you exported all of your packages and that you can also read any package exported by other modules. The problem is the module name part... The module name being derived from the jar name is a bit unpleasant, and it only takes one mistake in a build system to accidentally cause the module name to change. What the JPMS group ended up doing was to allow for people to say "Here's the module name we would use if we were ever to expend the effort to fully modularize the codebase" by adding an Automatic-Module-Name entry. That allows other projects to depend on the module name without any risk of it changing under them. The same "export everything, read everything" behaviour is preserved, but it just turns off the automatic module name inference.

@io7m
Copy link
Contributor Author

io7m commented Apr 21, 2020

On a related note, I really commend your up-to-date OSGi metadata. The fact that you've gone to the trouble of having OSGi headers with detailed imports and exports means that you're likely to have a relatively easy time if you ever attempt full JPMS modularization. It demonstrates that you've given some consideration as to the exposed ABI of the packages. 👍

rdeltour pushed a commit that referenced this issue May 1, 2020
This adds an Automatic-Module-Name manifest entry in order to allow
epubcheck to be used in a modular context without having to depend
on an unstable generated module name.

The module name is `org.w3c.epubcheck`, which is already used as the
bundle symbolic name in OSGi.

Fixes #1128
@rdeltour rdeltour added status: completed Work completed, can be closed and removed status: needs review Needs to be reviewed by a team member before further processing labels May 1, 2020
@rdeltour
Copy link
Member

rdeltour commented May 1, 2020

Thank you @io7m for the issue and the PR, it will be included in the next maintenance release (v4.2.3).

I also created issue #1137 as a reminder to try to provide a proper module descriptor.

@io7m
Copy link
Contributor Author

io7m commented May 1, 2020

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: medium To be processed and published in one of the upcoming releases status: completed Work completed, can be closed type: feature The issue describes a new feature request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants