Inline
Danno Ferrin wrote:
On Nov 25, 2015, at 6:49 PM, Kevin Rushforth
<kevin.rushfo...@oracle.com <mailto:kevin.rushfo...@oracle.com>> wrote:
1) I get the following error if I apply the patch and do a build:
:fxpackager:compileJava/localhome/kcr/javafx/9-jake-kcr/jfx/rt/modules/fxpackager/src/main/java/com/oracle/tools/packager/JLinkBundlerHelper.java:3:
error: package com.sun.tools.jdeps does not exist
import com.sun.tools.jdeps.Main;
^
Does this require a newer version of JDK9 jigsaw or is there some
other issue? If the former, then we need to solve a problem that
isn't yet solved with the build environment on our Hudson machines
before this can go in.
Do you have the module-info.java.extra file loaded up? It may be a
build issue since that file is not exported by default. Is this the
same error we see when it doen't like the module boundaries? do we
need to add some -XaddExports? It works for me, and the file is years
old, so it may be order or operations issues with the JDK that is on
the build server.
I'll look into building from a public EA build of Java 9 then (if I
have time, Chris or Dmitry may get to do that).
The JDK on the build server was built about 3 weeks ago and hasn't been
refreshed. We don't currently have a good way to take a JDK9 jigsaw
build that contains packager modules and use that to build fxpackager.
We will need a solution to this, so we don't have to keep generating two
builds -- one with and one without the packager bits, the latter being
what we currently need as the JDK9_HOME we use to build FX.
2) The JDK9_MODULES is a new variable that isn't currently defined.
What should it be set to? It looks like it is only used by the
packagerDev task, so might be OK.
Right now it is for packagerdev, but going forward I see it being
needed for the unit tests.
OK.
3) The classesModuleExclude mechanism duplicates an existing
mechanism to filter out classes from going into the modules. Are you
sure this new mechanism is needed? After I fixed
https://bugs.openjdk.java.net/browse/JDK-8142381 a couple weeks ago I
no longer see any classes from ant-javafx.jar showing up in the
fxpackager module.
I'll look into removing that code then.
Thanks.
-- Kevin
-- Kevin
Danno Ferrin wrote:
Here's the webrev: http://cr.openjdk.java.net/~shemnon/8080531/webrev.07/
<http://cr.openjdk.java.net/~shemnon/8080531/webrev.07/>
(it's been a stressful morning)
On Nov 25, 2015, at 9:38 AM, Danno Ferrin <danno.fer...@oracle.com> wrote:
Kevin, Chris, Dmitry
This is a bulk packager integration from the packager sandbox to the JavaFX
Sandbox, please review.
webrev:
There are three changes outside of the fxpackager module that I think Kevin
needs to give his approval for.
Two changes are in the build.gradle. The first adds a concept of
classesModuleExclude which is a regexp for files to exclude from the modular
jar. This is to support creating the ant jar outside of the module system so
that ant can read the required types and classes.
The second change is to introduce JDK9_MODULES, read off of an environmental
variable. This should point to your jmods directory (not explored modules,
this must be jmods). This is to support the packagerdev target which now needs
a pointer to the jmods which as of yet does not have a standard location
relative to the JDK/JRE.
The third change is the addition of another module-info.java.extra file. This
one exposes the invocation API for JDeps to packager so the detectmodules can
use it to sniff out modules from the classpath.
The remainder of the changes are internal to the fxpackager modules and
represent contributions from Chris Bensen, Dmitry Cherepanov, and myself
finishing out the last details for JEP275. This patch should make it feature
complete (but not bug complete, we got another milestone for that).
--Danno
