Bulk packager integration

[Kevin Rushforth]

Inline

Danno Ferrin wrote:
>
>> On Nov 25, 2015, at 6:49 PM, Kevin Rushforth 
>> <kevin.rushforth at oracle.com <mailto:kevin.rushforth at 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.ferrin at 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
>>>>     
>>>
>>>   
>