[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: Bulk packager integration
From:       Danno Ferrin <danno.ferrin () oracle ! com>
Date:       2015-11-30 15:19:39
Message-ID: 24C28C93-95A8-428C-B4FA-3B4D6B25DB45 () oracle ! com
[Download RAW message or body]


> On Nov 25, 2015, at 6:49 PM, Kevin Rushforth <kevin.rushforth@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). 

> 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.

> 
> 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 \
> <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.


> -- 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/> \
> > <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.ferrin@oracle.com> \
> > > <mailto:danno.ferrin@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
> > > 
> > 
> > 


[prev in list] [next in list] [prev in thread] [next in thread]