https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
r
• I'm totally uninterested in dynamic module loading at runtime - it's escaping from version collision hell I care about. (I dream of a world in which advertising your lib as "zero dependency" is a bad thing, because it means you've reimplemented loads of stuff that's done better elsewhere, because as a user of your library I just don't care about your 
implementation
scoped dependencies any more than I care about your 
private
classes and methods.) • I am really keen to avoid another metadata file. It's bad enough needing to keep Gradle dependencies & 
module-info.java
in sync. So Layrry for instance feels overkill. • I am really keen to make it transparent to the end user - they should still call 
java --module-path ... --module
or 
java -jar
. If the classpath / modulepath can be specified in META-INF or similar so much the better • I'd like it to be as light touch as possible in code - ideally a single call at the start of a 
main
method that would kick everything into this new world.
I've read the end of https://inside.java/2021/09/10/what-are-modules-about/ - I understand the further issues with trying to do this sort of thing. I have looked into 
ModuleLayer
, but I can't find a decent example of using it for what I want.
Or is there anywhere better to discuss this? I'm not sure if there's a JVM slack / discord! (I went for here on the basis that I'd be happy with something gradle specific using gradle's `api`/`implementation` distinction.)
j
It’s not really what you asked, but I have started a plugin that reads dependency information from the module info to address this (really bad imo) situation:
It’s bad enough needing to keep Gradle dependencies & 
module-info.java
in sync.
Maybe interesting for you. I still have to finde the time to polish that up more and make some things more configurable. Feedback is always welcome. https://github.com/jjohannes/java-module-dependencies
Some thoughts on the topic: -> If you do something like in the plugin, and the module-info is the source of truth, I assume you could use that information at runtime (?) (I am not so familiar with the APIs for that) -> If you want to do it based on what is defined in Gradle, you could generate a file that you then use at runtime that contains the information about which Jars on the classpath/modulepath are implementation dependencies of which of your “modules”. You could write a Gradle task that extracts the information from the 
compileClasspath
and writes that into a file you read at runtime to setup your classloading. It will be challenging to decide what to do if you also have sitations with “API dependencies” - I don’t think it’s trivial to implement something like this from scratch. Maybe Layrry is something you can use (I am not familiar with it), but generate the Layrry file with Gradle.
r
Your plugin is a really nice idea - will explore it.
Does it choose the implementation or the api configuration based on whether or not the module is exported?
j
Yes. 
requires
-> 
implementation
requires transitive
-> 
api
requires static
-> 
compileOnly
requires static transitive
-> 
compileOnlyApi
r
Awesome!
Pushing my luck, but does it work with testFixtures configurations? https://docs.gradle.org/current/userguide/java_testing.html#sec:java_test_fixtures
(Being lazy, should just try it…)
j
😄 It should. Plugin os looking at every source set and the module-info in the source set individually. But of course there might be bugs. If you try it and find something unexpected, feel free to file an issue.
🙏 1
👍 1
Open in Slack
PreviousNext
Powered by