On 2017-05-17 17:14, Erik Joelsson wrote:
Hah, that seems like a reasonable solution to me. The index page
generation shouldn't be heavy enough to be a problem here.
It's not the generation in itself, it's its dependencies that are heavy,
compared to plain docs-jdk-specs.
But, most use
Hah, that seems like a reasonable solution to me. The index page
generation shouldn't be heavy enough to be a problem here.
Looks good.
/Erik
On 2017-05-17 15:44, Magnus Ihse Bursie wrote:
On 2017-05-17 13:27, Erik Joelsson wrote:
I realize the dilemma. The clean solution is to define yet
On 2017-05-17 13:27, Erik Joelsson wrote:
I realize the dilemma. The clean solution is to define yet another top
level target for just this file. It's also possible that this race
will never cause problems, I don't know for sure.
Here's an updated version:
I realize the dilemma. The clean solution is to define yet another top
level target for just this file. It's also possible that this race will
never cause problems, I don't know for sure.
/Erik
On 2017-05-17 12:41, Magnus Ihse Bursie wrote:
On 2017-05-17 11:23, Erik Joelsson wrote:
Looks
On 2017-05-17 11:23, Erik Joelsson wrote:
Looks ok. Note that adding the global resources copy targets to two
different top level targets may cause race conditions in rare cases
depending on OS and file system.
Do you propose that I solve it in a different way? I was thinking of
moving the
Looks ok. Note that adding the global resources copy targets to two
different top level targets may cause race conditions in rare cases
depending on OS and file system.
/Erik
On 2017-05-17 10:16, Magnus Ihse Bursie wrote:
In JDK-8180208, a new top-level index.html for the entire docs image
In JDK-8180208, a new top-level index.html for the entire docs image was
created.
This should use the common jdk-default.css file, which should move out
of the specs directory.
Here is an example how the generated page looks like:
