From jonathan.gibbons at oracle.com Fri Feb 2 21:42:50 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 02 Feb 2018 13:42:50 -0800 Subject: RFR: 8195795: Organize javadoc output files by module/package, not just package Message-ID: <5A74DB5A.4030802@oracle.com> Please review changes, including a couple of small build changes, to reorganize the generated documentation into per-module directories. Build folk: the changes are just to move the generated module graph images into the new hierarchy. Javadoc folk: the changes are mostly simple, with most of the "magic" happening in the DocPaths factory class, creating old-style or new-style paths as appropriate. Care is taken in DocFilesHandlerImpl, where DocPath objects are used for input, and have to work in conjunction with the module Locations. Other than than, some factory methods moved from DocPath to DocPaths, and most factory methods were changed from static to instance methods, to be able to take the interim backwards-compatibility option into account. This work leverages JDK-8195796, to reduce the size of relative URLs in generated docs. JBS: https://bugs.openjdk.java.net/browse/JDK-8195795 CSR: https://bugs.openjdk.java.net/browse/JDK-8196112 Webrev: http://cr.openjdk.java.net/~jjg/8195795/webrev.00/ -- Jon From erik.joelsson at oracle.com Fri Feb 2 21:56:40 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 2 Feb 2018 13:56:40 -0800 Subject: RFR: 8195795: Organize javadoc output files by module/package, not just package In-Reply-To: <5A74DB5A.4030802@oracle.com> References: <5A74DB5A.4030802@oracle.com> Message-ID: <0095177d-48c8-d8ad-f002-25ae740c9413@oracle.com> Build change looks good to me. /Erik On 2018-02-02 13:42, Jonathan Gibbons wrote: > Please review changes, including a couple of small build changes, to > reorganize the generated > documentation into per-module directories. > > Build folk: the changes are just to move the generated module graph > images into the new hierarchy. > > Javadoc folk: the changes are mostly simple, with most of the "magic" > happening in the DocPaths factory class, creating old-style or > new-style paths as appropriate. Care is taken in DocFilesHandlerImpl, > where DocPath objects are used for input, and have to work in > conjunction with the module Locations.? Other than than, some factory > methods moved from DocPath to DocPaths, and most factory methods were > changed from static to instance methods, to be able to take the > interim backwards-compatibility option into account. > > This work leverages JDK-8195796, to reduce the size of relative URLs > in generated docs. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8195795 > CSR: https://bugs.openjdk.java.net/browse/JDK-8196112 > Webrev: http://cr.openjdk.java.net/~jjg/8195795/webrev.00/ > > -- Jon From mandy.chung at oracle.com Fri Feb 2 22:02:11 2018 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 2 Feb 2018 14:02:11 -0800 Subject: RFR: 8195795: Organize javadoc output files by module/package, not just package In-Reply-To: <5A74DB5A.4030802@oracle.com> References: <5A74DB5A.4030802@oracle.com> Message-ID: <7be2e3f1-d8da-64ce-a75f-a99d7dabb07c@oracle.com> $MODULE-graph.png to $MODULE/module-graph.png change looks fine. Mandy On 2/2/18 1:42 PM, Jonathan Gibbons wrote: > Please review changes, including a couple of small build changes, to > reorganize the generated > documentation into per-module directories. > > Build folk: the changes are just to move the generated module graph > images into the new hierarchy. > > Javadoc folk: the changes are mostly simple, with most of the "magic" > happening in the DocPaths factory class, creating old-style or > new-style paths as appropriate. Care is taken in DocFilesHandlerImpl, > where DocPath objects are used for input, and have to work in > conjunction with the module Locations.? Other than than, some factory > methods moved from DocPath to DocPaths, and most factory methods were > changed from static to instance methods, to be able to take the > interim backwards-compatibility option into account. > > This work leverages JDK-8195796, to reduce the size of relative URLs > in generated docs. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8195795 > CSR: https://bugs.openjdk.java.net/browse/JDK-8196112 > Webrev: http://cr.openjdk.java.net/~jjg/8195795/webrev.00/ > > -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Sat Feb 3 00:35:36 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 02 Feb 2018 16:35:36 -0800 Subject: RFR: JDK-8196736: Refactor HelpWriter and properties Message-ID: <5A7503D8.3000506@oracle.com> Please review a very simple renaming/refactoring of the code and properties used to generate the Help page, as a precursor to updating the content. This step does not change the relevant content of the generated page at all. JBS: https://bugs.openjdk.java.net/browse/JDK-8196736 Webrev: http://cr.openjdk.java.net/~jjg/8196736/webrev.00/ -- Jon From kumar.x.srinivasan at oracle.com Mon Feb 5 18:03:46 2018 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 05 Feb 2018 10:03:46 -0800 Subject: RFR: JDK-8196736: Refactor HelpWriter and properties In-Reply-To: <5A7503D8.3000506@oracle.com> References: <5A7503D8.3000506@oracle.com> Message-ID: <5A789C82.2010708@oracle.com> Hi Jon, Looks good. Kumar > Please review a very simple renaming/refactoring of the code and > properties used to generate the Help page, as a precursor to updating > the content. > > This step does not change the relevant content of the generated page > at all. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8196736 > Webrev: http://cr.openjdk.java.net/~jjg/8196736/webrev.00/ > > -- Jon > > From bhavesh.x.patel at oracle.com Mon Feb 5 21:58:26 2018 From: bhavesh.x.patel at oracle.com (Bhavesh Patel) Date: Mon, 5 Feb 2018 13:58:26 -0800 Subject: RFR: JDK-8196736: Refactor HelpWriter and properties In-Reply-To: <5A789C82.2010708@oracle.com> References: <5A7503D8.3000506@oracle.com> <5A789C82.2010708@oracle.com> Message-ID: <84fa2938-f106-19ca-1816-44e3b0e7f5e8@oracle.com> Thanks for pushing the fix out. Just one point to note. The help page is missing documentation for modules. Not sure if there is a bug for that in the JBS. Regards, Bhavesh. On 2/5/2018 10:03 AM, Kumar Srinivasan wrote: > > Hi Jon, > > Looks good. > > Kumar > >> Please review a very simple renaming/refactoring of the code and >> properties used to generate the Help page, as a precursor to updating >> the content. >> >> This step does not change the relevant content of the generated page >> at all. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8196736 >> Webrev: http://cr.openjdk.java.net/~jjg/8196736/webrev.00/ >> >> -- Jon >> >> > From bhavesh.x.patel at oracle.com Tue Feb 6 21:26:35 2018 From: bhavesh.x.patel at oracle.com (Bhavesh Patel) Date: Tue, 6 Feb 2018 13:26:35 -0800 Subject: RFR: 8196027: Remove "Prev" and "Next" links from the javadoc navigation In-Reply-To: <5A6DE271.4060502@oracle.com> References: <1964f2c7-6268-5c2a-ea2e-53a81239968e@oracle.com> <5A69286F.5020005@oracle.com> <892cd2be-5df8-ed9b-ecaf-a3ded0ebadf0@oracle.com> <5A6BA880.10702@oracle.com> <5A6DE271.4060502@oracle.com> Message-ID: <06dc5bf1-c848-4066-576f-2bc59e8a4fe0@oracle.com> Thanks Kumar. I have made the changes. Please review the updated patch at http://cr.openjdk.java.net/~bpatel/8196027/webrev.02/. Please see my response inline. On 1/28/2018 6:47 AM, Kumar Srinivasan wrote: > > Hi Bhavesh, > > || > *src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java* > > Could you please check the following and remove the computations for > prev, next > likely the ListIterator could be simplified to a for-loop. > 240 protected void generateClassFiles(SortedSet arr, ClassTree classtree) > 241 throws DocletException { > 242 List list = new ArrayList<>(arr); > 243 ListIterator iterator = list.listIterator(); > 244 TypeElement klass = null; > 245 while (iterator.hasNext()) { > 246 TypeElement prev = iterator.hasPrevious() ? klass : null; > 247 klass = iterator.next(); > 248 TypeElement next = iterator.nextIndex() == list.size() > 249 ? null : list.get(iterator.nextIndex()); >> I have updated this and changed it to a for loop. In addition to this, I have also updated generateModuleFiles() and generatePackageFiles() to remove the prev and next computations. > > *test/langtools/jdk/javadoc/doclet/testNavigation/TestModuleNavigation.java > * > 25 * @test > 26 * @bug 8196027 > 27 * @summary test that navigation links > ?? >> I have updated the summary. > Kumar > > >> Looks OK to me. >> >> -- Jon >> >> >> On 01/24/2018 09:23 PM, Bhavesh Patel wrote: >>> >>> Please see my response inline. I have made the recommended changes >>> and have uploaded the updated webrev at >>> http://cr.openjdk.java.net/~bpatel/8196027/webrev.01/. There are a >>> few new files in this review from which I have deleted the dead code. >>> >>> >>> On 1/24/2018 4:44 PM, Jonathan Gibbons wrote: >>>> >>>> >>>> On 01/24/2018 01:25 PM, Bhavesh Patel wrote: >>>>> Hi, >>>>> ????? Please review the fix for change in javadoc navigation bar. >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8196027. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~bpatel/8196027/webrev.00/ >>>>> >>>>> Regards, >>>>> Bhavesh. >>>> >>>> >>>> In SplitIndexWriter, there are still remnants remaining, such as >>>> prev/next fields. >>>> See lines 63-73. >>>> >>>> In Contents, there are more remnants, such as the set of prev/next >>>> labels. >>>> See lines 143-147, 158-162 >>> >>> Yes. Missed those unused variables. I have removed them from the >>> classes you mentioned and others where its no longer used. Also, I >>> have removed unused imports from these files. >>> >>>> >>>> In the new test, checkOutput(file, false, ...) tests are >>>> notoriously weak and fragile. >>>> In general you want to make them as broad as possible. To that end, >>>> I would suggest >>>> turning most "+" in lines 81-111 into a comma at the end of the >>>> previous line, >>>> and reduce all the strings down to either "Next"/"Prev" or >>>> "Next WORD"/"Prev WORD". >>> >>> I have updated the test. >>> >>>> >>>> -- Jon >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kumar.x.srinivasan at oracle.com Tue Feb 6 21:38:27 2018 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 06 Feb 2018 13:38:27 -0800 Subject: RFR: 8196027: Remove "Prev" and "Next" links from the javadoc navigation In-Reply-To: <06dc5bf1-c848-4066-576f-2bc59e8a4fe0@oracle.com> References: <1964f2c7-6268-5c2a-ea2e-53a81239968e@oracle.com> <5A69286F.5020005@oracle.com> <892cd2be-5df8-ed9b-ecaf-a3ded0ebadf0@oracle.com> <5A6BA880.10702@oracle.com> <5A6DE271.4060502@oracle.com> <06dc5bf1-c848-4066-576f-2bc59e8a4fe0@oracle.com> Message-ID: <5A7A2053.90604@oracle.com> I looked at the only changes I suggested. Ok with me. Thanks Kumar > > Thanks Kumar. I have made the changes. Please review the updated patch > at http://cr.openjdk.java.net/~bpatel/8196027/webrev.02/. Please see > my response inline. > > > On 1/28/2018 6:47 AM, Kumar Srinivasan wrote: >> >> Hi Bhavesh, >> >> || >> *src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java* >> >> Could you please check the following and remove the computations for >> prev, next >> likely the ListIterator could be simplified to a for-loop. >> 240 protected void generateClassFiles(SortedSet arr, ClassTree classtree) >> 241 throws DocletException { >> 242 List list = new ArrayList<>(arr); >> 243 ListIterator iterator = list.listIterator(); >> 244 TypeElement klass = null; >> 245 while (iterator.hasNext()) { >> 246 TypeElement prev = iterator.hasPrevious() ? klass : null; >> 247 klass = iterator.next(); >> 248 TypeElement next = iterator.nextIndex() == list.size() >> 249 ? null : list.get(iterator.nextIndex()); > > >> I have updated this and changed it to a for loop. In addition to > this, I have also updated generateModuleFiles() and > generatePackageFiles() to remove the prev and next computations. > >> >> *test/langtools/jdk/javadoc/doclet/testNavigation/TestModuleNavigation.java >> * >> 25 * @test >> 26 * @bug 8196027 >> 27 * @summary test that navigation links >> ?? > > >> I have updated the summary. > >> Kumar >> >> >>> Looks OK to me. >>> >>> -- Jon >>> >>> >>> On 01/24/2018 09:23 PM, Bhavesh Patel wrote: >>>> >>>> Please see my response inline. I have made the recommended changes >>>> and have uploaded the updated webrev at >>>> http://cr.openjdk.java.net/~bpatel/8196027/webrev.01/. There are a >>>> few new files in this review from which I have deleted the dead code. >>>> >>>> >>>> On 1/24/2018 4:44 PM, Jonathan Gibbons wrote: >>>>> >>>>> >>>>> On 01/24/2018 01:25 PM, Bhavesh Patel wrote: >>>>>> Hi, >>>>>> Please review the fix for change in javadoc navigation bar. >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8196027. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~bpatel/8196027/webrev.00/ >>>>>> >>>>>> Regards, >>>>>> Bhavesh. >>>>> >>>>> >>>>> In SplitIndexWriter, there are still remnants remaining, such as >>>>> prev/next fields. >>>>> See lines 63-73. >>>>> >>>>> In Contents, there are more remnants, such as the set of prev/next >>>>> labels. >>>>> See lines 143-147, 158-162 >>>> >>>> Yes. Missed those unused variables. I have removed them from the >>>> classes you mentioned and others where its no longer used. Also, I >>>> have removed unused imports from these files. >>>> >>>>> >>>>> In the new test, checkOutput(file, false, ...) tests are >>>>> notoriously weak and fragile. >>>>> In general you want to make them as broad as possible. To that >>>>> end, I would suggest >>>>> turning most "+" in lines 81-111 into a comma at the end of the >>>>> previous line, >>>>> and reduce all the strings down to either "Next"/"Prev" or >>>>> "Next WORD"/"Prev WORD". >>>> >>>> I have updated the test. >>>> >>>>> >>>>> -- Jon >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Feb 7 00:56:35 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 06 Feb 2018 16:56:35 -0800 Subject: RFR: 8196027: Remove "Prev" and "Next" links from the javadoc navigation In-Reply-To: <06dc5bf1-c848-4066-576f-2bc59e8a4fe0@oracle.com> References: <1964f2c7-6268-5c2a-ea2e-53a81239968e@oracle.com> <5A69286F.5020005@oracle.com> <892cd2be-5df8-ed9b-ecaf-a3ded0ebadf0@oracle.com> <5A6BA880.10702@oracle.com> <5A6DE271.4060502@oracle.com> <06dc5bf1-c848-4066-576f-2bc59e8a4fe0@oracle.com> Message-ID: <5A7A4EC3.1010207@oracle.com> OK -- Jon On 02/06/2018 01:26 PM, Bhavesh Patel wrote: > > > Thanks Kumar. I have made the changes. Please review the updated patch > at http://cr.openjdk.java.net/~bpatel/8196027/webrev.02/. Please see > my response inline. > > > On 1/28/2018 6:47 AM, Kumar Srinivasan wrote: >> >> Hi Bhavesh, >> >> || >> *src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java* >> >> Could you please check the following and remove the computations for >> prev, next >> likely the ListIterator could be simplified to a for-loop. >> 240 protected void generateClassFiles(SortedSet arr, ClassTree classtree) >> 241 throws DocletException { >> 242 List list = new ArrayList<>(arr); >> 243 ListIterator iterator = list.listIterator(); >> 244 TypeElement klass = null; >> 245 while (iterator.hasNext()) { >> 246 TypeElement prev = iterator.hasPrevious() ? klass : null; >> 247 klass = iterator.next(); >> 248 TypeElement next = iterator.nextIndex() == list.size() >> 249 ? null : list.get(iterator.nextIndex()); > > >> I have updated this and changed it to a for loop. In addition to > this, I have also updated generateModuleFiles() and > generatePackageFiles() to remove the prev and next computations. > >> >> *test/langtools/jdk/javadoc/doclet/testNavigation/TestModuleNavigation.java >> * >> 25 * @test >> 26 * @bug 8196027 >> 27 * @summary test that navigation links >> ?? > > >> I have updated the summary. > >> Kumar >> >> >>> Looks OK to me. >>> >>> -- Jon >>> >>> >>> On 01/24/2018 09:23 PM, Bhavesh Patel wrote: >>>> >>>> Please see my response inline. I have made the recommended changes >>>> and have uploaded the updated webrev at >>>> http://cr.openjdk.java.net/~bpatel/8196027/webrev.01/. There are a >>>> few new files in this review from which I have deleted the dead code. >>>> >>>> >>>> On 1/24/2018 4:44 PM, Jonathan Gibbons wrote: >>>>> >>>>> >>>>> On 01/24/2018 01:25 PM, Bhavesh Patel wrote: >>>>>> Hi, >>>>>> Please review the fix for change in javadoc navigation bar. >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8196027. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~bpatel/8196027/webrev.00/ >>>>>> >>>>>> Regards, >>>>>> Bhavesh. >>>>> >>>>> >>>>> In SplitIndexWriter, there are still remnants remaining, such as >>>>> prev/next fields. >>>>> See lines 63-73. >>>>> >>>>> In Contents, there are more remnants, such as the set of prev/next >>>>> labels. >>>>> See lines 143-147, 158-162 >>>> >>>> Yes. Missed those unused variables. I have removed them from the >>>> classes you mentioned and others where its no longer used. Also, I >>>> have removed unused imports from these files. >>>> >>>>> >>>>> In the new test, checkOutput(file, false, ...) tests are >>>>> notoriously weak and fragile. >>>>> In general you want to make them as broad as possible. To that >>>>> end, I would suggest >>>>> turning most "+" in lines 81-111 into a comma at the end of the >>>>> previous line, >>>>> and reduce all the strings down to either "Next"/"Prev" or >>>>> "Next WORD"/"Prev WORD". >>>> >>>> I have updated the test. >>>> >>>>> >>>>> -- Jon >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kumar.x.srinivasan at oracle.com Wed Feb 7 16:59:06 2018 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 07 Feb 2018 08:59:06 -0800 Subject: RFR: 8195795: Organize javadoc output files by module/package, not just package In-Reply-To: <5A74DB5A.4030802@oracle.com> References: <5A74DB5A.4030802@oracle.com> Message-ID: <5A7B305A.1050005@oracle.com> Hi Jon, Looks good to me, minor nits.... DocPaths.java long line: might exceed 100 chars + return (typeElement == null) ? DocPath.empty : forPackage(utils.containingPackage(typeElement)); suggest + return (typeElement == null) + ? DocPath.empty + : forPackage(utils.containingPackage(typeElement)); TestFrames.java I am uncertain of readability of breaking up the ternary operator here, since it is a lambda expression, I will leave it you. + .map(c -> (isInModule(c) ? (modulePart(c) + "/") : "") + packagePart(c) + "/package-frame.html") and + .map(c -> (isInModule(c) ? (modulePart(c) + "/") : "") + toHtml(packageClassPart(c))) Otherwise looks good,I don't need to see anotheriteration, if the changes are limited to style fix-ups. Thanks Kumar > Please review changes, including a couple of small build changes, to > reorganize the generated > documentation into per-module directories. > > Build folk: the changes are just to move the generated module graph > images into the new hierarchy. > > Javadoc folk: the changes are mostly simple, with most of the "magic" > happening in the DocPaths factory class, creating old-style or > new-style paths as appropriate. Care is taken in DocFilesHandlerImpl, > where DocPath objects are used for input, and have to work in > conjunction with the module Locations. Other than than, some factory > methods moved from DocPath to DocPaths, and most factory methods were > changed from static to instance methods, to be able to take the > interim backwards-compatibility option into account. > > This work leverages JDK-8195796, to reduce the size of relative URLs > in generated docs. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8195795 > CSR: https://bugs.openjdk.java.net/browse/JDK-8196112 > Webrev: http://cr.openjdk.java.net/~jjg/8195795/webrev.00/ > > -- Jon From jonathan.gibbons at oracle.com Wed Feb 7 17:58:58 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 07 Feb 2018 09:58:58 -0800 Subject: RFR: 8195795: Organize javadoc output files by module/package, not just package In-Reply-To: <5A7B305A.1050005@oracle.com> References: <5A74DB5A.4030802@oracle.com> <5A7B305A.1050005@oracle.com> Message-ID: <5A7B3E62.9000001@oracle.com> Thanks. I'll look at tweaking the style of the lines you mention. -- Jon On 02/07/2018 08:59 AM, Kumar Srinivasan wrote: > > Hi Jon, > > Looks good to me, minor nits.... > > DocPaths.java > > long line: might exceed 100 chars > > + return (typeElement == null) ? DocPath.empty : > forPackage(utils.containingPackage(typeElement)); > > > suggest > > + return (typeElement == null) > + ? DocPath.empty > + : forPackage(utils.containingPackage(typeElement)); > > TestFrames.java > > I am uncertain of readability of breaking up the ternary operator > here, since it is > a lambda expression, I will leave it you. > > + .map(c -> (isInModule(c) ? (modulePart(c) + "/") > : "") + packagePart(c) + "/package-frame.html") > > and > > + .map(c -> (isInModule(c) ? (modulePart(c) + "/") > : "") + toHtml(packageClassPart(c))) > > > > Otherwise looks good,I don't need to see anotheriteration, if the > changes are limited to style fix-ups. > > Thanks > Kumar > > >> Please review changes, including a couple of small build changes, to >> reorganize the generated >> documentation into per-module directories. >> >> Build folk: the changes are just to move the generated module graph >> images into the new hierarchy. >> >> Javadoc folk: the changes are mostly simple, with most of the "magic" >> happening in the DocPaths factory class, creating old-style or >> new-style paths as appropriate. Care is taken in DocFilesHandlerImpl, >> where DocPath objects are used for input, and have to work in >> conjunction with the module Locations. Other than than, some factory >> methods moved from DocPath to DocPaths, and most factory methods were >> changed from static to instance methods, to be able to take the >> interim backwards-compatibility option into account. >> >> This work leverages JDK-8195796, to reduce the size of relative URLs >> in generated docs. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8195795 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8196112 >> Webrev: http://cr.openjdk.java.net/~jjg/8195795/webrev.00/ >> >> -- Jon > From jonathan.gibbons at oracle.com Wed Feb 7 19:21:03 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 07 Feb 2018 11:21:03 -0800 Subject: RFR: 8195795: Organize javadoc output files by module/package, not just package In-Reply-To: <5A7B3E62.9000001@oracle.com> References: <5A74DB5A.4030802@oracle.com> <5A7B305A.1050005@oracle.com> <5A7B3E62.9000001@oracle.com> Message-ID: <5A7B519F.8040807@oracle.com> The following small set of changes are needed after merging the latest changes in the main repository. The conflicting changeset was that for this issue: JDK-8196027: Remove "Prev" and "Next" links from the javadoc navigation https://bugs.openjdk.java.net/browse/JDK-8196027 $ hg diff test/langtools/jdk/javadoc/doclet/testNavigation/TestModuleNavigation.java diff -r ba19a21d727d test/langtools/jdk/javadoc/doclet/testNavigation/TestModuleNavigation.java --- a/test/langtools/jdk/javadoc/doclet/testNavigation/TestModuleNavigation.java Wed Feb 07 09:48:43 2018 -0800 +++ b/test/langtools/jdk/javadoc/doclet/testNavigation/TestModuleNavigation.java Wed Feb 07 11:15:59 2018 -0800 @@ -82,23 +82,23 @@ "Prev", "Next"); - checkOutput("m-summary.html", false, + checkOutput("m/module-summary.html", false, "Prev Module", "Next Module"); - checkOutput("m2p1/package-summary.html", false, + checkOutput("m2/m2p1/package-summary.html", false, "Prev Package", "Next Package"); - checkOutput("m2p1/Am2.html", false, + checkOutput("m2/m2p1/Am2.html", false, "Prev Class", "Next Class"); - checkOutput("m2p1/class-use/Am2.html", false, + checkOutput("m2/m2p1/class-use/Am2.html", false, "Prev", "Next"); - checkOutput("m2p1/package-tree.html", false, + checkOutput("m2/m2p1/package-tree.html", false, "Prev", "Next"); -- Jon On 02/07/2018 09:58 AM, Jonathan Gibbons wrote: > Thanks. I'll look at tweaking the style of the lines you mention. > > -- Jon > > On 02/07/2018 08:59 AM, Kumar Srinivasan wrote: >> >> Hi Jon, >> >> Looks good to me, minor nits.... >> >> DocPaths.java >> >> long line: might exceed 100 chars >> >> + return (typeElement == null) ? DocPath.empty : >> forPackage(utils.containingPackage(typeElement)); >> >> >> suggest >> >> + return (typeElement == null) >> + ? DocPath.empty >> + : forPackage(utils.containingPackage(typeElement)); >> >> TestFrames.java >> >> I am uncertain of readability of breaking up the ternary operator >> here, since it is >> a lambda expression, I will leave it you. >> >> + .map(c -> (isInModule(c) ? (modulePart(c) + "/") >> : "") + packagePart(c) + "/package-frame.html") >> >> and >> >> + .map(c -> (isInModule(c) ? (modulePart(c) + "/") >> : "") + toHtml(packageClassPart(c))) >> >> >> >> Otherwise looks good,I don't need to see anotheriteration, if the >> changes are limited to style fix-ups. >> >> Thanks >> Kumar >> >> >>> Please review changes, including a couple of small build changes, to >>> reorganize the generated >>> documentation into per-module directories. >>> >>> Build folk: the changes are just to move the generated module graph >>> images into the new hierarchy. >>> >>> Javadoc folk: the changes are mostly simple, with most of the >>> "magic" happening in the DocPaths factory class, creating old-style >>> or new-style paths as appropriate. Care is taken in >>> DocFilesHandlerImpl, where DocPath objects are used for input, and >>> have to work in conjunction with the module Locations. Other than >>> than, some factory methods moved from DocPath to DocPaths, and most >>> factory methods were changed from static to instance methods, to be >>> able to take the interim backwards-compatibility option into account. >>> >>> This work leverages JDK-8195796, to reduce the size of relative URLs >>> in generated docs. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8195795 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8196112 >>> Webrev: http://cr.openjdk.java.net/~jjg/8195795/webrev.00/ >>> >>> -- Jon >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kumar.x.srinivasan at oracle.com Wed Feb 7 19:22:57 2018 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 07 Feb 2018 11:22:57 -0800 Subject: RFR: 8195795: Organize javadoc output files by module/package, not just package In-Reply-To: <5A7B519F.8040807@oracle.com> References: <5A74DB5A.4030802@oracle.com> <5A7B305A.1050005@oracle.com> <5A7B3E62.9000001@oracle.com> <5A7B519F.8040807@oracle.com> Message-ID: <5A7B5211.3050801@oracle.com> +1 Kumar On 2/7/2018 11:21 AM, Jonathan Gibbons wrote: > The following small set of changes are needed after merging the latest > changes in the main repository. > The conflicting changeset was that for this issue: > JDK-8196027: Remove "Prev" and "Next" links from the javadoc navigation > https://bugs.openjdk.java.net/browse/JDK-8196027 > > $ hg diff > test/langtools/jdk/javadoc/doclet/testNavigation/TestModuleNavigation.java > diff -r ba19a21d727d > test/langtools/jdk/javadoc/doclet/testNavigation/TestModuleNavigation.java > --- > a/test/langtools/jdk/javadoc/doclet/testNavigation/TestModuleNavigation.java > Wed Feb 07 09:48:43 2018 -0800 > +++ > b/test/langtools/jdk/javadoc/doclet/testNavigation/TestModuleNavigation.java > Wed Feb 07 11:15:59 2018 -0800 > @@ -82,23 +82,23 @@ > "Prev", > "Next"); > > - checkOutput("m-summary.html", false, > + checkOutput("m/module-summary.html", false, > "Prev Module", > "Next Module"); > > - checkOutput("m2p1/package-summary.html", false, > + checkOutput("m2/m2p1/package-summary.html", false, > "Prev Package", > "Next Package"); > > - checkOutput("m2p1/Am2.html", false, > + checkOutput("m2/m2p1/Am2.html", false, > "Prev Class", > "Next Class"); > > - checkOutput("m2p1/class-use/Am2.html", false, > + checkOutput("m2/m2p1/class-use/Am2.html", false, > "Prev", > "Next"); > > - checkOutput("m2p1/package-tree.html", false, > + checkOutput("m2/m2p1/package-tree.html", false, > "Prev", > "Next"); > > > -- Jon > > On 02/07/2018 09:58 AM, Jonathan Gibbons wrote: >> Thanks. I'll look at tweaking the style of the lines you mention. >> >> -- Jon >> >> On 02/07/2018 08:59 AM, Kumar Srinivasan wrote: >>> >>> Hi Jon, >>> >>> Looks good to me, minor nits.... >>> >>> DocPaths.java >>> >>> long line: might exceed 100 chars >>> >>> + return (typeElement == null) ? DocPath.empty : >>> forPackage(utils.containingPackage(typeElement)); >>> >>> >>> suggest >>> >>> + return (typeElement == null) >>> + ? DocPath.empty >>> + : forPackage(utils.containingPackage(typeElement)); >>> >>> TestFrames.java >>> >>> I am uncertain of readability of breaking up the ternary operator >>> here, since it is >>> a lambda expression, I will leave it you. >>> >>> + .map(c -> (isInModule(c) ? (modulePart(c) + >>> "/") : "") + packagePart(c) + "/package-frame.html") >>> >>> and >>> >>> + .map(c -> (isInModule(c) ? (modulePart(c) + >>> "/") : "") + toHtml(packageClassPart(c))) >>> >>> >>> >>> Otherwise looks good,I don't need to see anotheriteration, if the >>> changes are limited to style fix-ups. >>> >>> Thanks >>> Kumar >>> >>> >>>> Please review changes, including a couple of small build changes, >>>> to reorganize the generated >>>> documentation into per-module directories. >>>> >>>> Build folk: the changes are just to move the generated module graph >>>> images into the new hierarchy. >>>> >>>> Javadoc folk: the changes are mostly simple, with most of the >>>> "magic" happening in the DocPaths factory class, creating old-style >>>> or new-style paths as appropriate. Care is taken in >>>> DocFilesHandlerImpl, where DocPath objects are used for input, and >>>> have to work in conjunction with the module Locations. Other than >>>> than, some factory methods moved from DocPath to DocPaths, and most >>>> factory methods were changed from static to instance methods, to be >>>> able to take the interim backwards-compatibility option into account. >>>> >>>> This work leverages JDK-8195796, to reduce the size of relative >>>> URLs in generated docs. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8195795 >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8196112 >>>> Webrev: http://cr.openjdk.java.net/~jjg/8195795/webrev.00/ >>>> >>>> -- Jon >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Fri Feb 9 18:51:17 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 9 Feb 2018 10:51:17 -0800 Subject: RFR: 8194651: javadoc: mark the com.sun.javadoc API for removal In-Reply-To: <5A67B10F.9080706@oracle.com> References: <5A67B10F.9080706@oracle.com> Message-ID: <57de4599-9247-51f0-a5ff-689e77ec8ab4@oracle.com> OK -- Jon On 1/23/18 2:02 PM, Kumar Srinivasan wrote: > Hi, > > Please review fix for 8194651, > https://bugs.openjdk.java.net/browse/JDK-8194651 > Webrev: http://cr.openjdk.java.net/~ksrini/8194651/webrev.01/ > > Please note this is blocked by: JDK-8194764 > > Thanks > Kumar From martinrb at google.com Sat Feb 10 00:06:24 2018 From: martinrb at google.com (Martin Buchholz) Date: Fri, 9 Feb 2018 16:06:24 -0800 Subject: RFR: 8194651: javadoc: mark the com.sun.javadoc API for removal In-Reply-To: <57de4599-9247-51f0-a5ff-689e77ec8ab4@oracle.com> References: <5A67B10F.9080706@oracle.com> <57de4599-9247-51f0-a5ff-689e77ec8ab4@oracle.com> Message-ID: This seems to break the build * For target buildtools_interim_langtools_modules_jdk.javadoc.interim__the.BUILD_jdk.javadoc.interim_batch: /home/martin/ws/jdk/src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/SourcePositionImpl.java:31: warning: [removal] SourcePosition in com.sun.javadoc has been deprecated and marked for removal import com.sun.javadoc.SourcePosition; ^ error: warnings found and -Werror specified 1 error 1 warning On Fri, Feb 9, 2018 at 10:51 AM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > OK > > -- Jon > > > > On 1/23/18 2:02 PM, Kumar Srinivasan wrote: > >> Hi, >> >> Please review fix for 8194651, https://bugs.openjdk.java.net/ >> browse/JDK-8194651 >> Webrev: http://cr.openjdk.java.net/~ksrini/8194651/webrev.01/ >> >> Please note this is blocked by: JDK-8194764 >> >> Thanks >> Kumar >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kumar.x.srinivasan at oracle.com Sat Feb 10 00:43:18 2018 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 09 Feb 2018 16:43:18 -0800 Subject: RFR: 8194651: javadoc: mark the com.sun.javadoc API for removal In-Reply-To: <5A7E3B5A.8050506@oracle.com> References: <5A67B10F.9080706@oracle.com> <57de4599-9247-51f0-a5ff-689e77ec8ab4@oracle.com> <5A7E3B5A.8050506@oracle.com> Message-ID: <5A7E4026.5090908@oracle.com> Martin, Jon, Yes this one: https://bugs.openjdk.java.net/browse/JDK-8194764 When I filed the above bug, I could only reproduce the above only with langtools/make ant script, this issue never showed up while building the jdk, because of this http://hg.openjdk.java.net/jdk/jdk/file/5e2d2067da48/make/common/SetupJavaCompilers.gmk#l34 Has the above been changed ? even so with JDK-8194764, it should not happen. Kumar On 2/9/2018 4:22 PM, Jonathan Gibbons wrote: > Martin, > > I'm not hearing any CI alarm bells ringing here, and I've just > completed a clean build of the latest bits in jdk/jdk repo. > > There was a related javac fix that went back a few days ago, from Jan > Lahoda. Is it possible that either you didn't pick up that fix, or > that you have a locally modified copy of javadoc that needs to be updated? > > -- Jon > > On 02/09/2018 04:06 PM, Martin Buchholz wrote: >> This seems to break the build >> >> * For target >> buildtools_interim_langtools_modules_jdk.javadoc.interim__the.BUILD_jdk.javadoc.interim_batch: >> /home/martin/ws/jdk/src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/SourcePositionImpl.java:31: >> warning: [removal] SourcePosition in com.sun.javadoc has been >> deprecated and marked for removal >> import com.sun.javadoc.SourcePosition; >> ^ >> error: warnings found and -Werror specified >> 1 error >> 1 warning >> >> >> On Fri, Feb 9, 2018 at 10:51 AM, Jonathan Gibbons >> > wrote: >> >> OK >> >> -- Jon >> >> >> >> On 1/23/18 2:02 PM, Kumar Srinivasan wrote: >> >> Hi, >> >> Please review fix for 8194651, >> https://bugs.openjdk.java.net/browse/JDK-8194651 >> >> Webrev: http://cr.openjdk.java.net/~ksrini/8194651/webrev.01/ >> >> >> Please note this is blocked by: JDK-8194764 >> >> Thanks >> Kumar >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Sat Feb 10 00:22:50 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 09 Feb 2018 16:22:50 -0800 Subject: RFR: 8194651: javadoc: mark the com.sun.javadoc API for removal In-Reply-To: References: <5A67B10F.9080706@oracle.com> <57de4599-9247-51f0-a5ff-689e77ec8ab4@oracle.com> Message-ID: <5A7E3B5A.8050506@oracle.com> Martin, I'm not hearing any CI alarm bells ringing here, and I've just completed a clean build of the latest bits in jdk/jdk repo. There was a related javac fix that went back a few days ago, from Jan Lahoda. Is it possible that either you didn't pick up that fix, or that you have a locally modified copy of javadoc that needs to be updated? -- Jon On 02/09/2018 04:06 PM, Martin Buchholz wrote: > This seems to break the build > > * For target > buildtools_interim_langtools_modules_jdk.javadoc.interim__the.BUILD_jdk.javadoc.interim_batch: > /home/martin/ws/jdk/src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/SourcePositionImpl.java:31: > warning: [removal] SourcePosition in com.sun.javadoc has been > deprecated and marked for removal > import com.sun.javadoc.SourcePosition; > ^ > error: warnings found and -Werror specified > 1 error > 1 warning > > > On Fri, Feb 9, 2018 at 10:51 AM, Jonathan Gibbons > > wrote: > > OK > > -- Jon > > > > On 1/23/18 2:02 PM, Kumar Srinivasan wrote: > > Hi, > > Please review fix for 8194651, > https://bugs.openjdk.java.net/browse/JDK-8194651 > > Webrev: http://cr.openjdk.java.net/~ksrini/8194651/webrev.01/ > > > Please note this is blocked by: JDK-8194764 > > Thanks > Kumar > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Sat Feb 10 06:36:34 2018 From: martinrb at google.com (Martin Buchholz) Date: Fri, 9 Feb 2018 22:36:34 -0800 Subject: RFR: 8194651: javadoc: mark the com.sun.javadoc API for removal In-Reply-To: <5A7E3B5A.8050506@oracle.com> References: <5A67B10F.9080706@oracle.com> <57de4599-9247-51f0-a5ff-689e77ec8ab4@oracle.com> <5A7E3B5A.8050506@oracle.com> Message-ID: I can confirm that it is this commit: changeset: 48840:5e2d2067da48 tip user: ksrini date: 2018-02-09 13:58 -0800 8194651: javadoc: mark the com.sun.javadoc API for removal Reviewed-by: jjg that causes a build failure when rebuilding from scratch. I bisected my configure flags - it's the boot jdk bash ./configure --with-boot-jdk=/home/martin/jdk/jdk10 fails while bash ./configure --with-boot-jdk=/home/martin/jdk/jdk9 succeeds. Y'all are probably still using jdk9 as bootstrap. But as you all know, it's been the rule since time immemorial to use JDK N-1 to bootstrap JDK N. On Fri, Feb 9, 2018 at 4:22 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > Martin, > > I'm not hearing any CI alarm bells ringing here, and I've just completed a > clean build of the latest bits in jdk/jdk repo. > > There was a related javac fix that went back a few days ago, from Jan > Lahoda. Is it possible that either you didn't pick up that fix, or that you > have a locally modified copy of javadoc that needs to be updated? > > -- Jon > > > On 02/09/2018 04:06 PM, Martin Buchholz wrote: > > This seems to break the build > > * For target buildtools_interim_langtools_modules_jdk.javadoc.interim__ > the.BUILD_jdk.javadoc.interim_batch: > /home/martin/ws/jdk/src/jdk.javadoc/share/classes/com/sun/ > tools/javadoc/main/SourcePositionImpl.java:31: warning: [removal] > SourcePosition in com.sun.javadoc has been deprecated and marked for removal > import com.sun.javadoc.SourcePosition; > ^ > error: warnings found and -Werror specified > 1 error > 1 warning > > > On Fri, Feb 9, 2018 at 10:51 AM, Jonathan Gibbons < > jonathan.gibbons at oracle.com> wrote: > >> OK >> >> -- Jon >> >> >> >> On 1/23/18 2:02 PM, Kumar Srinivasan wrote: >> >>> Hi, >>> >>> Please review fix for 8194651, https://bugs.openjdk.java.net/ >>> browse/JDK-8194651 >>> Webrev: http://cr.openjdk.java.net/~ksrini/8194651/webrev.01/ >>> >>> Please note this is blocked by: JDK-8194764 >>> >>> Thanks >>> Kumar >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Sat Feb 10 16:20:13 2018 From: martinrb at google.com (Martin Buchholz) Date: Sat, 10 Feb 2018 08:20:13 -0800 Subject: RFR: 8194651: javadoc: mark the com.sun.javadoc API for removal In-Reply-To: <5A7EA819.4080403@oracle.com> References: <5A67B10F.9080706@oracle.com> <57de4599-9247-51f0-a5ff-689e77ec8ab4@oracle.com> <5A7E3B5A.8050506@oracle.com> <5A7EA819.4080403@oracle.com> Message-ID: OK, I get it now. jdk tip needs http://hg.openjdk.java.net/jdk/jdk10/rev/107413b070b9 *in the bootstrap* to bootstrap with jdk10, but that is coming out as part of jdk-10+43, which hasn't been released yet. So this will fix itself over time. I can confirm that jdk tip bootstraps with jdk 10 tip and fails with jdk-10+42. (It would be nice if it jdk bootstrap was less brittle) On Sat, Feb 10, 2018 at 12:06 AM, Jan Lahoda wrote: > Hi Martin, > > Does your JDK 10 build have the following fix? > http://hg.openjdk.java.net/jdk/jdk10/rev/107413b070b9 > > I tried and the build indeed fails when using JDK 10 without this fix as a > bootstrap, but does not (seem to) fail when using JDK 10 with this fix. > >> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Sat Feb 10 16:30:56 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sat, 10 Feb 2018 08:30:56 -0800 Subject: RFR: 8194651: javadoc: mark the com.sun.javadoc API for removal In-Reply-To: References: <5A67B10F.9080706@oracle.com> <57de4599-9247-51f0-a5ff-689e77ec8ab4@oracle.com> <5A7E3B5A.8050506@oracle.com> <5A7EA819.4080403@oracle.com> Message-ID: <07ea3ec0-2636-e115-3910-b1e9c8cff2fa@oracle.com> Martin, Thanks for the investigation and the update.? Sorry for the inconvenience. -- Jon On 2/10/18 8:20 AM, Martin Buchholz wrote: > OK, I get it now. jdk tip needs > http://hg.openjdk.java.net/jdk/jdk10/rev/107413b070b9 *in the > bootstrap* to bootstrap with jdk10, but that is coming out as part of > jdk-10+43, which hasn't been released yet.? So this will fix itself > over time.? I can confirm that jdk tip bootstraps with jdk 10 tip and > fails with jdk-10+42. > > (It would be nice if it jdk bootstrap was less brittle) > > On Sat, Feb 10, 2018 at 12:06 AM, Jan Lahoda > wrote: > > Hi Martin, > > Does your JDK 10 build have the following fix? > http://hg.openjdk.java.net/jdk/jdk10/rev/107413b070b9 > > > I tried and the build indeed fails when using JDK 10 without this > fix as a bootstrap, but does not (seem to) fail when using JDK 10 > with this fix. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Sat Feb 10 08:06:49 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Sat, 10 Feb 2018 09:06:49 +0100 Subject: RFR: 8194651: javadoc: mark the com.sun.javadoc API for removal In-Reply-To: References: <5A67B10F.9080706@oracle.com> <57de4599-9247-51f0-a5ff-689e77ec8ab4@oracle.com> <5A7E3B5A.8050506@oracle.com> Message-ID: <5A7EA819.4080403@oracle.com> Hi Martin, Does your JDK 10 build have the following fix? http://hg.openjdk.java.net/jdk/jdk10/rev/107413b070b9 I tried and the build indeed fails when using JDK 10 without this fix as a bootstrap, but does not (seem to) fail when using JDK 10 with this fix. Jan > From: *Martin Buchholz* > > Date: Sat, Feb 10, 2018 at 7:36 AM > Subject: Re: RFR: 8194651: javadoc: mark the com.sun.javadoc API for removal > To: Jonathan Gibbons > > Cc: javadoc-dev > > > > I can confirm that it is this commit: > > changeset: 48840:5e2d2067da48 tip > user: ksrini > date: 2018-02-09 13:58 -0800 > 8194651: javadoc: mark the com.sun.javadoc API for removal > Reviewed-by: jjg > > that causes a build failure when rebuilding from scratch. > > I bisected my configure flags - it's the boot jdk > > bash ./configure --with-boot-jdk=/home/martin/jdk/jdk10 > fails while > bash ./configure --with-boot-jdk=/home/martin/jdk/jdk9 > succeeds. > > Y'all are probably still using jdk9 as bootstrap. > > But as you all know, it's been the rule since time immemorial to use JDK > N-1 to bootstrap JDK N. > > > > On Fri, Feb 9, 2018 at 4:22 PM, Jonathan Gibbons > > wrote: > > Martin, > > I'm not hearing any CI alarm bells ringing here, and I've just > completed a clean build of the latest bits in jdk/jdk repo. > > There was a related javac fix that went back a few days ago, from > Jan Lahoda. Is it possible that either you didn't pick up that fix, > or that you have a locally modified copy of javadoc that needs to be > updated? > > -- Jon > > > On 02/09/2018 04:06 PM, Martin Buchholz wrote: >> This seems to break the build >> >> * For target >> buildtools_interim_langtools_modules_jdk.javadoc.interim__the.BUILD_jdk.javadoc.interim_batch: >> /home/martin/ws/jdk/src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/SourcePositionImpl.java:31: >> warning: [removal] SourcePosition in com.sun.javadoc has been >> deprecated and marked for removal >> import com.sun.javadoc.SourcePosition; >> ^ >> error: warnings found and -Werror specified >> 1 error >> 1 warning >> >> >> On Fri, Feb 9, 2018 at 10:51 AM, Jonathan Gibbons >> > >> wrote: >> >> OK >> >> -- Jon >> >> >> >> On 1/23/18 2:02 PM, Kumar Srinivasan wrote: >> >> Hi, >> >> Please review fix for 8194651, >> https://bugs.openjdk.java.net/browse/JDK-8194651 >> >> Webrev: >> http://cr.openjdk.java.net/~ksrini/8194651/webrev.01/ >> >> >> Please note this is blocked by: JDK-8194764 >> >> Thanks >> Kumar >> >> >> > > > From bhavesh.x.patel at oracle.com Wed Feb 21 22:22:50 2018 From: bhavesh.x.patel at oracle.com (Bhavesh Patel) Date: Wed, 21 Feb 2018 14:22:50 -0800 Subject: RFR: Javadoc search broken after output files organization for modules Message-ID: <189c13ac-21f1-fa66-1125-a09dba5ca464@oracle.com> Hi, ??? This is the fix for javadoc search that was broken after the output files organization for modules. As a part of the fix, search.js is updated to accommodate these changes.The URLs will be calculated correctly if --no-module-directories command-line option is used. I have tested the output for module and non-module directory structure. In terms of tests, we do not have much of automated testing in this area so only checking the variable that is set for the directory mode and the actual script changes are being checked. I have also tested the offline bundles and it works fine with the change. JBS: https://bugs.openjdk.java.net/browse/JDK-8198522 Webrev: http://cr.openjdk.java.net/~bpatel/8198522/webrev/ Regards, Bhavesh. From jonathan.gibbons at oracle.com Fri Feb 23 21:35:59 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 23 Feb 2018 13:35:59 -0800 Subject: RFR: Javadoc search broken after output files organization for modules In-Reply-To: <189c13ac-21f1-fa66-1125-a09dba5ca464@oracle.com> References: <189c13ac-21f1-fa66-1125-a09dba5ca464@oracle.com> Message-ID: Generally looks OK to me. The fix still assumes unique package names, so a good follow-up enhancement would be to facilitate duplicate package names in different modules. -- Jon On 2/21/18 2:22 PM, Bhavesh Patel wrote: > Hi, > ??? This is the fix for javadoc search that was broken after the > output files organization for modules. As a part of the fix, search.js > is updated to accommodate these changes.The URLs will be calculated > correctly if --no-module-directories command-line option is used. I > have tested the output for module and non-module directory structure. > In terms of tests, we do not have much of automated testing in this > area so only checking the variable that is set for the directory mode > and the actual script changes are being checked. I have also tested > the offline bundles and it works fine with the change. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8198522 > Webrev: http://cr.openjdk.java.net/~bpatel/8198522/webrev/ > > Regards, > Bhavesh.