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

Add simple module-info for JDK9+, using Moditect #527

Merged
merged 2 commits into from
Mar 7, 2019

Conversation

cowtowncoder
Copy link
Member

As per title. For 2.x will use moduleInfoFile which allows build using JDK 8, but is quite inconvenient as it can not do wildcard exports; will upgrade in 3.0, and probably for components other than jackson-core / jackson-annotations.

@cowtowncoder
Copy link
Member Author

@GedMarc similar to annotations one. I think I need to consider JDK 11 for build for other components, to be able to use wildcards for export definitions (and probably for imports too).

@GedMarc
Copy link

GedMarc commented Mar 5, 2019

Yeaaahhh, no Wildcards ;) I tried my heart out, but it isn't osgi xD

We found out on this thread (moditect/moditect#90 (comment)) that it is actually purely cosmetic from the compiler, the output class knows nothing of it - the output class actually has everything expanded.

I put my module info's on the thread for annotations (FasterXML/jackson-annotations#151)

They seem to be doing the trick quite nicely, and JLink is building like a star

@cowtowncoder
Copy link
Member Author

cowtowncoder commented Mar 5, 2019

Ok thanks -- will leave output at base then, as that did seem to work. Plus planning to do 2.10.0.rc1 (or is it pr1, either way) to give others chance to see if there are problems.
Thank you for adding other module infos; as I said I'll have to think about JDK used to build; maybe only keeping annotations/streaming/databind at JDK 8 (since those probably are most important to avoid adding accidental deps to post-jdk8 types).

Wildcards are a bummer but I can understand why this is, if code is relying on JDK 9+ functionality for heavy lifting (and not reinventing the wheel) of expanding.
So for JDK 8 it can only copy things as-is (I am guessing), but with later it can process syntactic sugar and produce actual exact settings for module-info.
The only thing other wrt Moditect is that it'd be nice if exception was handled in a way to make this more clear (and mention in README). Maybe I should file an issue.

@cowtowncoder
Copy link
Member Author

Alas, Moditect seems quite half-baked tool, giving obscure errors on about any input :-( :-( :-(
In particular I just can't figure out how to generate package-info without either

[ERROR] Failed to execute goal org.moditect:moditect-maven-plugin:1.0.0.Beta2:generate-module-info (default-cli) on project aalto-xml: Execution default-cli of goal org.moditect:moditect-maven-plugin:1.0.0.Beta2:generate-module-info failed. NullPointerException -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException

or

[ERROR] Failed to execute goal org.moditect:moditect-maven-plugin:1.0.0.Beta2:generate-module-info (generate-module-info) on project aalto-xml: Execution generate-module-info of goal org.moditect:moditect-maven-plugin:1.0.0.Beta2:generate-module-info failed: Encountered unexpected token: "-" "-"
[ERROR] at line 1, column 20.
[ERROR] 
[ERROR] Was expecting:
[ERROR] 
[ERROR] <EOF>
[ERROR] 
[ERROR] Problem stacktrace :
[ERROR] com.github.javaparser.GeneratedJavaParser.generateParseException(GeneratedJavaParser.java:10419)
[ERROR] com.github.javaparser.GeneratedJavaParser.jj_consume_token(GeneratedJavaParser.java:10278)
[ERROR] com.github.javaparser.GeneratedJavaParser.NameParseStart(GeneratedJavaParser.java:5785)
[ERROR] com.github.javaparser.JavaParser.parse(JavaParser.java:136)
[ERROR] com.github.javaparser.JavaParser.simplifiedParse(JavaParser.java:342)
[ERROR] com.github.javaparser.JavaParser.parseName(JavaParser.java:503)

@GedMarc
Copy link

GedMarc commented Mar 6, 2019

Naw Moditect is everywhere and though its beta it is very stable, classgraph guice, primefaces, etc...

Null Pointer is usually a very wrong module file, P.S> rather use an actual module-info.java file, with an attach-sources for JDK11 and up

This lets you build the module file in JDK 11, and simply switch a profile to test the forwards compatibility,

P.P.S.
No import statements, No Wildcards. Always full referencing (Pity you named the SPI "Module" though, perhaps think about giving it a new name in v3)

@cowtowncoder
Copy link
Member Author

Including actual module-info.java does work; and although there isn't meaningful semantic validation at least syntax is validated by plug-in. So we'll go with this.

@cowtowncoder
Copy link
Member Author

Yeah, Module was chosen well before Java 9, and is quite baked-in by now. Major compatibility issue to change that, although as usual could change in 3.0. I guess most users do not interact with that type, so base interface could become JacksonModule I guess.

As to NPE and other exceptions these are with jackson-core, aalto, so nothing broken about code, only set up of module info and/or plugin configuration. I'm sure there's some reason for failure, but error reporting really is rather bad and I hope maintainers can improve upon it, esp. same useless exceptions were thrown with JDK 11, not just 8.

But be that as it may not much I can do about that.

@cowtowncoder cowtowncoder merged commit 951d073 into 2.10 Mar 7, 2019
@cowtowncoder cowtowncoder added this to the 2.10.0 milestone Mar 7, 2019
cowtowncoder added a commit that referenced this pull request Mar 7, 2019
@@ -0,0 +1,19 @@
module com.fasterxml.jackson.core {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel your pain. Note ModiTect would allow you to use wildcards (com.fasterxml.jackson.core.*) if you were to use it on JDK 9 or later. It will then generate the actual descriptor exporting all packages matching the wildcard.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok that is good to know going forward. While Jackson 2.x will probably not go beyond JDK 8, 3.x will at some point so that's good info.

@gunnarmorling
Copy link

About the NPE, have you figured what is triggering it? If you file an issue ideally containing a small reproducer project, I can take a look.

@cowtowncoder
Copy link
Member Author

No, I didn't. I haven't seen it with other projects, for what that is worth. If I bump into it again, I will try to get reproducible test case & file an issue. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants