On Thu, 17 Dec 2020 04:48:44 GMT, Jonathan Gibbons wrote:
>> OK: valid
>> OBSOLETE: obsolete, deprecated, but still supported (valid)
>> UNSUPPORTED: ever supported but no longer supported (invalid)
>> INVALID: the rest of others (invalid)
>>
>> UNSUPPORTED can be used if we would like to
On Thu, 17 Dec 2020 04:52:48 GMT, Jonathan Gibbons wrote:
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties
>> line 36:
>>
>>> 34: dc.attr.img.border.not.number = attribute "border" for img is not a
>>> number
>>> 35: dc.attr.table.border.not.valid =
On Thu, 17 Dec 2020 01:40:14 GMT, Yoshiki Sato wrote:
>> HTML4 is no longer supported in javadoc.
>>
>> doclint needs to drop HTML4 support as well.
>> The changes consist of:
>> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
>> * Sorting out supported tags and
On Thu, 17 Dec 2020 04:50:59 GMT, Jonathan Gibbons wrote:
>> Yoshiki Sato has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views will show differences
>> compared to the previous content of the PR. The pull request contains one
>> new
On Thu, 12 Nov 2020 03:10:01 GMT, Yoshiki Sato wrote:
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlTag.java line
>> 410:
>>
>>> 408: OBSOLETE,
>>> 409: UNSUPPORTED
>>> 410: }
>>
>> On one hand, I don't think we need this level of detail, but on the
> HTML4 is no longer supported in javadoc.
>
> doclint needs to drop HTML4 support as well.
> The changes consist of:
> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
> * Sorting out supported tags and attributes in HTML5 (including fix incorrect
> permission of valign
> This is for JDK16, as a precursor to fixing JDK-8258002.
>
> While it is good to be using localized strings in the generated output, the
> significance for JDK-8258002 is that the strings are now obtained from a
> resource file, and not hardcoded in JavaScript file itself.
>
> The source
On Mon, 14 Dec 2020 09:11:31 GMT, Hannes Wallnöfer wrote:
>> This is for JDK16, as a precursor to fixing JDK-8258002.
>>
>> While it is good to be using localized strings in the generated output, the
>> significance for JDK-8258002 is that the strings are now obtained from a
>> resource file,
On Tue, 15 Dec 2020 16:11:45 GMT, Magnus Ihse Bursie wrote:
> The hard-coded list of modules in `make/common/Modules.gmk` has always been a
> wart in the build system. We pride ourself on using discovery instead of
> hard-coded list. In this case, it is not possible to do do auto-discovery,
>
On Wed, 16 Dec 2020 18:36:25 GMT, Magnus Ihse Bursie wrote:
>> The hard-coded list of modules in `make/common/Modules.gmk` has always been
>> a wart in the build system. We pride ourself on using discovery instead of
>> hard-coded list. In this case, it is not possible to do do auto-discovery,
On Wed, 16 Dec 2020 18:36:25 GMT, Magnus Ihse Bursie wrote:
>> The hard-coded list of modules in `make/common/Modules.gmk` has always been
>> a wart in the build system. We pride ourself on using discovery instead of
>> hard-coded list. In this case, it is not possible to do do auto-discovery,
On Tue, 15 Dec 2020 23:28:25 GMT, Magnus Ihse Bursie wrote:
> The hotspot launcher script is misplaced among the hotspot make files. It
> should move to make/scripts (and get a proper extension).
This pull request has now been integrated.
Changeset: ab5d581b
Author:Magnus Ihse Bursie
On Thu, 10 Dec 2020 23:07:52 GMT, Naoto Sato wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Move to share/data, and move jdwp.spec to java.se
>
> Reviewed changes to `characterdata`, `charsetmapping`,
> The hard-coded list of modules in `make/common/Modules.gmk` has always been a
> wart in the build system. We pride ourself on using discovery instead of
> hard-coded list. In this case, it is not possible to do do auto-discovery,
> since the different module sets are configured, not
On Thu, 5 Nov 2020 16:16:44 GMT, Pavel Rappo wrote:
>> Jonathan Gibbons has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains 11 commits:
>>
>> - Fix merge issues; review feedback
>> - Merge with master
>> - allow rich content in
On Thu, 22 Oct 2020 02:40:44 GMT, Jonathan Gibbons wrote:
> This introduces support for a new `@spec` tag that can be used as either an
> inline tag or as a block tag. It is used to identify references to external
> specifications, in such a way that the references can be collected together
>
On Wed, 16 Dec 2020 14:40:14 GMT, Alan Bateman wrote:
> javadoc-modules.conf is probably okay although someone finding this in the
> repo might initially think it's the configuration for the javadoc modules.
> That plus it sets DOCS_MODULES, so maybe it should be apidocs-modules.conf.
I'm
On Tue, 15 Dec 2020 23:28:25 GMT, Magnus Ihse Bursie wrote:
> The hotspot launcher script is misplaced among the hotspot make files. It
> should move to make/scripts (and get a proper extension).
The rename and makefile changes look good.
I've used the script on occasion, but not recently (not
On Wed, 16 Dec 2020 13:51:50 GMT, Magnus Ihse Bursie wrote:
>> The update to JRE_MODULES in Images.gmk resolves my comment above. However,
>> the naming for the configuration is still a bit odd, e.g.
>> module-sets-classloaders.conf should be something like
>> module-loader-map.conf as used
On Wed, Dec 16, 2020 at 3:20 PM Robin Westberg
wrote:
> Hi Thomas,
>
> > On 16 Dec 2020, at 14:54, Thomas Stüfe wrote:
> >
> > Hi Robin,
> >
> > does this mean tests won't run on branches which cannot be merged with
> the
> > assumed target branch?
>
> No, if there’s a problem with doing the
Hi Thomas,
> On 16 Dec 2020, at 14:54, Thomas Stüfe wrote:
>
> Hi Robin,
>
> does this mean tests won't run on branches which cannot be merged with the
> assumed target branch?
No, if there’s a problem with doing the merge the tests will simply continue
without doing it, and just use the
On Wed, 16 Dec 2020 10:12:54 GMT, Alan Bateman wrote:
>> I think this is almost ready to be pushed, but I'd like to have someone from
>> the client team review the changes for java.desktop as well. @prrace Any
>> change you can have a look at this?
>
> I think it will be annoying to have the
On Wed, 16 Dec 2020 10:21:08 GMT, Alan Bateman wrote:
>> @mlchung The entire point of this exercise is to *not* have hard-coded lists
>> of modules in make files...
>>
>> Having hard-coded lists have come back to bite us, time after time again. We
>> try to auto-discover everything that is
Hi Robin,
does this mean tests won't run on branches which cannot be merged with the
assumed target branch?
Thanks, Thomas
On Wed, Dec 16, 2020 at 11:55 AM Robin Westberg
wrote:
> Normally when running GitHub Actions on a pull request, what is checked
> out is the merge of the pull request
> The hard-coded list of modules in `make/common/Modules.gmk` has always been a
> wart in the build system. We pride ourself on using discovery instead of
> hard-coded list. In this case, it is not possible to do do auto-discovery,
> since the different module sets are configured, not
On Tue, 15 Dec 2020 17:50:46 GMT, Magnus Ihse Bursie wrote:
> In `Docs.gmk` there are some hard-coded links to online URL documentation and
> bug reporting locations. These should not reside in the make file per se, but
> instead move to the `make/conf` directory.
This pull request has now
On Tue, 15 Dec 2020 17:50:46 GMT, Magnus Ihse Bursie wrote:
> In `Docs.gmk` there are some hard-coded links to online URL documentation and
> bug reporting locations. These should not reside in the make file per se, but
> instead move to the `make/conf` directory.
Okay.
-
Marked
Normally when running GitHub Actions on a pull request, what is checked out is
the merge of the pull request with the latest changes on the target branch.
This ensure that what is tested is as close as possible to what will actually
be the result of integrating said pull request.
In our use
On Wed, 16 Dec 2020 00:14:02 GMT, Magnus Ihse Bursie wrote:
>> Can any of `INTERIM_IMAGE_MODULES` , `HOTSPOT_MODULES` and
>> `LANGTOOLS_MODULES` be inlined in the appropriate .gmk file?
>>
>> `INTERIM_IMAGE_MODULES` is for building interim image. If it has to be
>> defined in a conf file, I
On Tue, 15 Dec 2020 22:52:30 GMT, Magnus Ihse Bursie wrote:
>> Reviewed changes to `characterdata`, `charsetmapping`, `cldr`, `currency`,
>> `lsrdata`, `tzdata`, and `unicodedata` with minor comment. Looks good
>> overall.
>
> I think this is almost ready to be pushed, but I'd like to have
30 matches
Mail list logo
