I fixed that but the webrev.02 missed to include this line fix (sorry about
that):
-BUILD_TOOLS_JDK := $(call SetupJavaCompilationCompileTarget, \
+BUILD_JIGSAW_TOOLS := $(call SetupJavaCompilationCompileTarget, \
BUILD_JIGSAW_TOOLS, $(TOOLS_CLASSES_DIR))
I’ll include ifndef as you suggested.
Mandy
> On Mar 29, 2017, at 4:45 AM, Magnus Ihse Bursie
> <[email protected]> wrote:
>
> On 2017-03-25 22:33, Mandy Chung wrote:
>> I edited the module descriptions per your feedback. I also revised
>> GenGraphs tool to take a properties file to customize the dot graphs
>> for javadoc use.
>>
>> Updated webrev:
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173303/webrev.02/
>> <http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173303/webrev.02/>I just
>> discovered a problem with this patch when I tried to apply it locally.
>
> With this patch, it is not possible to run "make docs-javadoc" in a clean
> build. The problem is that ModuleTools.gmk is broken, and overrides the value
> of BUILD_TOOLS_JDK from Tools.gmk.
>
> /Magnus
>
>> Magnus, Erik,
>>
>> I modified Javadoc.gmk and Main.gmk to add a new target to generate
>> .dot files for javadoc use. GenGraphs tool depends on the exploded
>> image build. Javadoc.gmk temporarily takes ENABLE_MODULE_GRAPH make
>> variable for us to enable @moduleGraph taglet until JDK-8176785 is
>> resolved.
>>
>> thanks
>> Mandy
>>
>>> On Mar 25, 2017, at 2:36 AM, Alan Bateman <[email protected]>
>>> <mailto:[email protected]> wrote:
>>>
>>> On 24/03/2017 21:50, Mandy Chung wrote:
>>>
>>>> Alan,
>>>>
>>>> I took another round of edits on the module descriptions:
>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173303/webrev.01/
>>>> <http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173303/webrev.01/>
>>>>
>>>> Once we have the unified docs, it will make it easier to review
>>>> the module summary page for all modules where we will revise
>>>> these module descriptions again.
>>>>
>>> I went through the updated module descriptions.
>>>
>>> Two more that seem to be missing "the" are jdk.net and jdk.sctp, I think
>>> they will read okay once that is added.
>>>
>> Fixed. I missed that.
>>
>>> jdk.httpserver currently has "Defines the JDK-specific API for HTTP
>>> server", it might be better to re-shuffle this to "Defines the API for the
>>> JDK-specific HTTP server”.
>>>
>> This reads better.
>>
>>> I think the only one that needs re-examination is jdk.charsets. The
>>> java.base module contains the standard charsets and all other charsets
>>> needed to start the runtime on any of the supported configurations. It thus
>>> varies by platform with jdk.charsets providing the charsets that aren't in
>>> java.base. Finding the right description is difficult, maybe we should
>>> start with "Charset provider for the charsets that are not in java.base
>>> (mostly double byte and IBM charsets". I could imagine linking this to the
>>> "Supported encodings" docs page in time.
>>>
>> Let’s start with this version. I expect we will refine the module
>> description further next couple weeks.
>>
>>> Everything else looks good.
>>
>> Thanks
>> Mandy
>
