jlink --add-modules ALL-MODULE-PATH does not work in this patch since
the default module is added after the roots set is computed.
AppRuntimeImageBuilder could calls its moduleFinder method (that calls
JlinkTask::newModuleFinder). packager may already provide the default
module path and we will leave it for them to create the ModuleFinder.
JlinkConfiguration constructor taking ModuleFinder does not need to take
modulepaths and limitmods (I think getModulePaths and getLimitedmods are
not used). If we change AppRuntimeImageBuilder to pass ModuleFinder to
JlinkConfiguration constructor, tests are the remaining one using the
existing constructor and perhaps we should consider updating the test
and drop the existing constructor.
I agree that getDefaultModulePath should be moved JlinkTask.
Mandy
On 10/25/17 6:43 AM, Sundararajan Athijegannathan wrote:
Second constructor is used by packager (internal) api. I could move
getDefaultModulePath to JlinkTask..
-Sundar
On 25/10/17, 6:25 PM, Alan Bateman wrote:
On 25/10/2017 11:23, Sundararajan Athijegannathan wrote:
Updated: http://cr.openjdk.java.net/~sundar/8189777/webrev.03/
This looks better. A few comments/questions:
Does the JlinkConfiguration constructor that takes the ModuleFinder
still need the module path? I assume it shouldn't be needed now
(getModulepaths() seems unused). Also is the second constructor
needed? I ask because the second constructor as it callbacks back to
JlinkTask which seems a bit odd.
Is JlinkConfiguration the right place for getDefaultModulePath? It
might be clearer to do that in JlinkTask.
-Alan
