Open tlinkowski opened 5 years ago
This would add this as an option, while the current behavior is still supported as well, correct? Looks like a great idea. I originally thought about doing this as the default behavior, but wasn't sure at the time if that would be flexible enough. Having both options would be really good.
We should make it very clear in the doc what the recommended approach is, it's potentially confusing (but not wrong) that there are two ways to achieve the same thing. I think the new approach should be the preferred approach, since that usually what you need anyway.
This would add this as an option, while the current behavior is still supported as well, correct?
Yes, definitely:
task.moduleOptions
modularity
ModularityExtension
won't even be stateful — it'll just set the options in the tasks' moduleOptions
.
We should make it very clear in the doc what the recommended approach is [...]. I think the new approach should be the preferred approach, since that usually what you need anyway.
Agree.
It seems as if your comments only concerned point no. 1, am I right? Do you have any thoughts about point no. 2? Or can I just assume you agree with it too?
@paulbakker, let me know if you'd be interested in accepting PRs for the following:
1. Adding convenience methods
modularity.addModules
, etc.ModuleOptions
for various tasks (compileJava
,compileTestJava
,test
,javadoc
,run
) currently share the following four config options:addModules
,addReads
,addExports
, andaddOpens
. However, all of them have to be set separately for every task.I propose adding convenience methods to
ModularityExtension
that would append to those config options for all applicable tasks.Signatures:
For example
modularity.addModules 'java.sql'
would add modulejava.sql
to all the tasks.This is related to #76.
2. Adding convenience method
modularity.patchModules
I suggest adding:
For consistency, I changed the signature from
List<String>
(where strings are separated with=
) toMap<String, String>
so that it aligns withaddReads
,addExports
, andaddOpens
(introduced by #74).This would let us call:
instead of
Moreover, since
javac
's--patch-module
supports patching multiple JARs into a module (separated with:
), this method would allow such notation. For example:would map to
I also propose deprecating direct
patchModules
extension usage.