-
Notifications
You must be signed in to change notification settings - Fork 105
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
Introduce full module-info.java
#127
Comments
module-info.java
I've put the module descriptors in place. Would you mind building the current snapshots locally and giving the results a try? |
I'm just looking at the commit. You're going to want to put compilation is fine, but I have no idea what the impact of having an automatic-module in the same jar as one with a module-info is. I don't think you need to strip it out for kotlin, but I haven't tested. You should be able to add comprehensive tests by adding a module-info to your test suites. That will also require you to rename the test suite package. |
Remove automatic module names from manifests. Additionally open packages for reflection.
That's great feedback, thanks! I've removed the automatic module names and added the |
You don't have to do what I'm about to say, I'm not certain I recommend it. I prefer explicitness. repeat this is just an FYI. You could write this instead. I forgot it existed because none of the modules I've been developing are pure API and so I prefer to be explicit as I don't need things like spring iterating over util packages. It effectively does the same thing. YMMV, just thought I'd mention it since I saw it on javas docs when I was looking for something else.
note: going to give the latest snapshot a test, either later today, or perhaps tomorrow. |
Updated, thanks! 🙇 |
Remove automatic module names from manifests. Additionally open packages for reflection.
#47 is great, but I think that these jars are ideal candidates to have a full
module-info.java
perhaps using the java9 (like jspecify does) directory if java 8 compatibility is required. This actually causes a real problem for future compatibility here. Since the DDD interfaces are part of your API a consumer should be usingrequires transient
but JPMS warns if you do this for an automatic-module.I'd be willing to put in some legwork here.
The text was updated successfully, but these errors were encountered: