Community
Participate
Working Groups
When bug 186342 is released we'll need to update the user documentation accordingly.
Setting milestone to match that of bug 186342
As part of this: -we need to put all new JavaCore and CompilerOptions APIs (with javadocs) into buildnotes. (I think there's one new API in IBinaryMethod as well) -update jdt_api_options.html with new JavaCore options.
> -we need to put all new JavaCore and CompilerOptions APIs (with javadocs) into > buildnotes. (I think there's one new API in IBinaryMethod as well) > -update jdt_api_options.html with new JavaCore options. Please hold on doing this until tomorrow. I'm making a pass over the new APIs and I'll release my tweaks today.
I've - released my API tweaks - added the org.eclipse.jdt.annotation package to the generated Javadocs in org.eclipse.jdt.doc.isv - added org.eclipse.jdt.core.compiler.batch as well (Javadoc was also missing for that package) http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=d204f81f44a990ae74280d415d69da53964a3837 http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=da649570ee80bda3b883c695dce0395584a727ef
I've adopted Markus' tweaks into the buildnotes in http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=58f6afc12cba62ef8d27c501894e3dd000ed5c7a (plus a couple more cosmetic fixes).
Created attachment 207873 [details] additions to jdt_api_options.htm This is my take at jdt_api_options.htm. Some entries are longer than usual on that page. Should those be shortened, or is it OK to basically take the version from the javadoc? I should probably also update ref-preferences-errors-warnings.html -- then reflecting the new structure of the preference page. BTW: it seems we missed to update this one for the new t-w-r warnings.
Ayush, Please give it an once over. TIA.
There was a bug in the doc of potential null spec violation (the doc was actually of insufficient info for null analysis). > I should probably also update ref-preferences-errors-warnings.html -- Done. > BTW: it seems we missed to update this one for the new t-w-r warnings. We usually make a pass just before every release. So we'll include this at that time. Released via http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=2dfd1662619dfdfaf2702951491881385120bebc Thanks Stephan, let me know if you find anything amiss.
(In reply to comment #8) > Released via > http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=2dfd1662619dfdfaf2702951491881385120bebc > > Thanks Stephan, let me know if you find anything amiss. I just noted that Kim had to revert this patch because IT BROKE THE BUILD. I'm not sure how that can happen, but I can see that one of the HTML links misses the closing quotes on the href argument. My bad. Apolologies! Not sure if that was the cause, but that's my best guess currently. Unfortunately, I can't see the build error any more. Need to find out how building the doc-plugin can be tested locally, perhaps simply by using the export plug-in wizard?
(In reply to comment #9) > I just noted that Kim had to revert this patch because IT BROKE THE BUILD. > I'm not sure how that can happen, but I can see that one of the HTML links > misses the closing quotes on the href argument. Thanks for the pointer Stephan. I fixed this and released via commit 17a33e21f64db9b8223663d78ab0feb0417eade7. Also verified by doing an export of the isv plugin.
(In reply to comment #10) > (In reply to comment #9) > > I just noted that Kim had to revert this patch because IT BROKE THE BUILD. > > I'm not sure how that can happen, but I can see that one of the HTML links > > misses the closing quotes on the href argument. > Thanks for the pointer Stephan. I fixed this and released via commit > 17a33e21f64db9b8223663d78ab0feb0417eade7. > Also verified by doing an export of the isv plugin. Thanks Ayush, so without the closing quote, does the isv plugin export fail ? OIOW, do we have a way of verification for this round and for future ?
(In reply to comment #11) > Thanks Ayush, so without the closing quote, does the isv plugin export fail ? Yes > OIOW, do we have a way of verification for this round and for future ? We should verify using an HTML validator such as http://htmlhelp.com/tools/validator/ and then export the plugin. Thats all we can do.
I found more problems with the HTML using the validator. :( released via commit 6b856193133b4ecd667ef02366c559974e525315
Looks like this is my bad! Apologies. The JDT UI team runs chkpii tests before doing the build input which catch these sort of errors. Yesterday after the tests were run and I started to do the build input I saw that the doc bundles were on 'integration' branch and hence did not have the latest changes from master. I thought that the worst case scenario would be that some html would not be perfect but I did not imagine that the build would fail! I will run the tests again with Ayush's commit and see if there are any more issues.
(In reply to comment #12) > (In reply to comment #11) > > Thanks Ayush, so without the closing quote, does the isv plugin export fail ? > Yes > > OIOW, do we have a way of verification for this round and for future ? > We should verify using an HTML validator such as > http://htmlhelp.com/tools/validator/ and then export the plugin. Thats all we > can do. Ayush, Can we get the opinion straight from the horse's mouth : The w3 consortium has a validator at http://validator.w3.org/. Thanks for checking this out and reporting status here.
The tests report one problem git/eclipse.platform.common/bundles/org.eclipse.jdt.doc.user/reference/preferences/java/compiler/ ref-preferences-errors-warnings.htm HTML-40 808 Unmatched (B /B) tag on/after TRN line: 826 808 Unmatched (B /B) tag on/after TRN line: 826
(In reply to comment #16) > The tests report one problem > > git/eclipse.platform.common/bundles/org.eclipse.jdt.doc.user/reference/preferences/java/compiler/ > ref-preferences-errors-warnings.htm HTML-40 808 > Unmatched (B /B) tag on/after TRN line: 826 > 808 > Unmatched (B /B) tag on/after TRN line: 826 Fixed with commit 6b856193133b4ecd667ef02366c559974e525315
(In reply to comment #17) > Fixed with commit 6b856193133b4ecd667ef02366c559974e525315 Thats not right. The actual commit is 703464499057b35f8d4e172c92b0a7b69a87ec24.
Created attachment 207968 [details] jdt api options file
Created attachment 207969 [details] ref-preferences-errors-warnings file
Kim, the integration branch has been restored to a sane state and is the same as master. The next build should not have any problems.
(In reply to comment #19) > Created attachment 207968 [details] > jdt api options file This file passes validation cleanly. (In reply to comment #20) > Created attachment 207969 [details] > ref-preferences-errors-warnings file w3c validator reports: Line 807, Column 6: end tag for element "TR" which is not open Line 896, Column 6: end tag for element "P" which is not open Line 913, Column 6: end tag for element "P" which is not open Line 932, Column 6: end tag for element "P" which is not open
Created attachment 207973 [details] fixed ref-preferences-errors file (In reply to comment #22) > Line 807, Column 6: end tag for element "TR" which is not open > Line 896, Column 6: end tag for element "P" which is not open > Line 913, Column 6: end tag for element "P" which is not open > Line 932, Column 6: end tag for element "P" which is not open Fixed with commit c74571b29396093e419db61b13215040d92ba2bb
A few comments regarding ref-preferences-errors.htm: - the entry for "Potential null pointer access" mentions the limitations of the analysis - we might want to add a reference to null annotations here. E.g.: "The quality of the analysis can be improved by using null-annotations, which can be enabled using the option <b>Enable annotation-based null analysis</b>." - entry "Use non-null as workspace-wide default" should account for the fact that the label changes to ".. project-wide default", when configuring per-project preferences - watch out for the citation in the "Redundnant null annotation" entry. Other than that everything in that file looks good to me. Thanks!
(In reply to comment #24) > A few comments regarding ref-preferences-errors.htm: Thanks. I've included this in bug 365662. After breaking the build because of the doc, spending a day fixing the repo and fighting with git, we're freezing the doc at this point :)
(In reply to comment #25) > (In reply to comment #24) > > A few comments regarding ref-preferences-errors.htm: > Thanks. I've included this in bug 365662. After breaking the build because of > the doc, spending a day fixing the repo and fighting with git, we're freezing > the doc at this point :) Oh, my! I've added my latest finding to that bug, too.
(In reply to comment #25) > (In reply to comment #24) > > A few comments regarding ref-preferences-errors.htm: > Thanks. I've included this in bug 365662. After breaking the build because of > the doc, spending a day fixing the repo and fighting with git, we're freezing > the doc at this point :) Ayush, please raise a bug against egit/git with what ever information we have. It is scary if a push can modify in the remote repository files of a project that are not even imported into a workspace. It appeared that for a few weeks, we managed to keep the time sink demons at bay. Not for long it turns out, oh well :(
I have a spelling question: I once learned that the plural of "analysis" is "analyses". However, in http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=703464499057b35f8d4e172c92b0a7b69a87ec24 this "spelling error" was "corrected" to "these analysis". I don't want to start an edit war :) hence I'm asking here what *is* the correct plural?
(In reply to comment #28) > I have a spelling question: I once learned that the plural of "analysis" > is "analyses". However, in > http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=703464499057b35f8d4e172c92b0a7b69a87ec24 > this "spelling error" was "corrected" to "these analysis". > > I don't want to start an edit war :) hence I'm asking here what *is* > the correct plural? You are right - http://dictionary.reference.com/browse/analysis Sorry, I saw a spelling error at the location and 'fixed' it. Feel free to revert the change. (Or I can do it tomorrow)
(In reply to comment #27) > (In reply to comment #25) > > (In reply to comment #24) > > > A few comments regarding ref-preferences-errors.htm: > > Thanks. I've included this in bug 365662. After breaking the build because of > > the doc, spending a day fixing the repo and fighting with git, we're freezing > > the doc at this point :) > > Ayush, please raise a bug against egit/git with what ever information we have. For the record, the bug raised is: https://bugs.eclipse.org/bugs/show_bug.cgi?id=365778
(In reply to comment #29) > (In reply to comment #28) > > I have a spelling question: I once learned that the plural of "analysis" > > is "analyses". However, in > > http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=703464499057b35f8d4e172c92b0a7b69a87ec24 > > this "spelling error" was "corrected" to "these analysis". > > > > I don't want to start an edit war :) hence I'm asking here what *is* > > the correct plural? > > You are right - http://dictionary.reference.com/browse/analysis > > Sorry, I saw a spelling error at the location and 'fixed' it. Feel free to > revert the change. (Or I can do it tomorrow) Fixed it this morning.
Build Id: N20111206-1150 In the JDT/Core options page, the hyperlinks to COMPILER_ANNOTATION_NULL_ANALYSIS brings up a blank page. This seem to point to JavaCore#COMPILER_ANNOTATION_NULL_ANALYSIS, which is not present. Has this already been fixed?
(In reply to comment #32) > In the JDT/Core options page, the hyperlinks to > COMPILER_ANNOTATION_NULL_ANALYSIS brings up a blank page. This seem to point to > JavaCore#COMPILER_ANNOTATION_NULL_ANALYSIS, which is not present. Has this > already been fixed? Looks like the links to that particular option are pointing to JavaCore#... instead of JavaCore.html#...
(In reply to comment #33) > Looks like the links to that particular option are pointing to JavaCore#... > instead of JavaCore.html#... Released in HEAD. Changes are here: http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=a8090457ed202cc041447ad7e36938efc1fff13e
(In reply to comment #34) > (In reply to comment #33) > > Looks like the links to that particular option are pointing to JavaCore#... > > instead of JavaCore.html#... > > Released in HEAD. Changes are here: > http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=a8090457ed202cc041447ad7e36938efc1fff13e Thanks Jay. Please also mark this as Verified if there's no other issue.
Looks like the latest fixes did not make it into the build and hence we have CHKPII errors in our M4 candidate. I've released this into 'integration' now.
http://git.eclipse.org/c/platform/eclipse.platform.common.git/log/?h=integration The last few commits do not have a tag on them which means that they have not made it to a build, and that other than CHKPII errors there are also a few broken links in the build. I distinctly remember doing the build input yesterday evening and verifying the tags on git.eclipse.org, and before that Satyam and Ayush had merged till the following commit http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?h=integration&id=c74571b29396093e419db61b13215040d92ba2bb by which point the fix for the CHKPII error was already in. For a while I even thought that I was hallucinating about doing the build input, but looks like I am ok :-) I just downloaded build I20111207-2118 i.e. http://download.eclipse.org/eclipse/downloads/drops/I20111207-2118/index.php This build includes - org.eclipse.jdt.doc.isv_3.8.0.v20111205-2016.jar - org.eclipse.jdt.doc.user_3.8.0.v20111205-0928.jar But it does NOT include any documentation related to null annotations in this file - /org.eclipse.jdt.doc.isv/guide/jdt_api_options.htm. However some documentation should be there as indicated by commit http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=a8090457ed202cc041447ad7e36938efc1fff13e Now looking at http://git.eclipse.org/c/platform/eclipse.platform.common.git/ I do not see the tag 'v20111205-2016' on a commit, however it is shown under the 'Tag' section. I think v20111205-2016 reflects the state when Kim backed out changes which caused the build to fail, see http://dev.eclipse.org/mhonarc/lists/platform-releng-dev/msg19369.html. The zombie state of 'v20111205-2016' was probably caused while rewriting the history to fix the git issues we had on Tuesday. I think the problem of fixes not making it to the build is caused by the fact that v20111205-2016 is not present on any commit which confuses the auto-tagging scripts. 2 questions now - how do we fix this? - do we need a rebuild for M4? (I would guess so, since some documentation is missing, no?)
I20111205-1800 build also includes org.eclipse.jdt.doc.isv_3.8.0.v20111205-2016.
(In reply to comment #37) > I think the problem of fixes not making it to the build is caused by the fact > that v20111205-2016 is not present on any commit which confuses the > auto-tagging scripts. The tag points to a commit that exists in the repo, but it is not a parent of the master or integration branch: http://git.eclipse.org/c/platform/eclipse.platform.common.git/tag/?id=v20111205-2016 I think the best solution is to just do the build input manually (push a new tag and update the map file). I'll do this.
- The fix needs to be verified on the next integration build. - If the fix works, we should probably file a bug against the auto-tagging scripts to handle zombie tags.
This looks a case study in concurrent multiple failures: - Malformed html got released into master. - Process glitch that carried this over to integration bypassing sanity tests. - EGit bug in messing up permissions. - w3c validator finding issues in what passes though our tools, (this has only curiousity/academic value in the current episode) - Potential glitch in integration tagging scripts - Concluding we are on terra firma having checked against nightly build. For having contributed to Act 1 - Scene 1 and also to the last scene of this drama (as of now ;-)), JDT/Core team would apologize to all. Bottom line: - You can't be paranoid enough (TM) Good news: We are tightening our processes so that documentation checkin will be prevalidated for markup errors. Jay, please check against I builds. Can we check for both 3.8 and 4.2 builds please ? (See note on bottom line above :))
Sigh.. The CHKPII error is still there, see http://download.eclipse.org/eclipse/downloads/drops/I20111208-1305/testresults/chkpii/linux.gtk.x86_6.0_org.eclipse.nls.html.txt Though the missing doc problem should have been resolved (I have not verified this though). http://download.eclipse.org/eclipse/downloads/drops/I20111208-1305/directory.txt - this shows that the v20111208-1301 tag was used for doc.isv plugin. (In reply to comment #39) > I think the best solution is to just do the build input manually (push a new > tag and update the map file). I'll do this. Markus only updated the tag for doc.isv plugin. And for some reason the tag on doc.user plugin has not been updated in the map file by the auto-tagging scripts.
(In reply to comment #42) > The CHKPII error is still there, see > http://download.eclipse.org/eclipse/downloads/drops/I20111208-1305/testresults/chkpii/linux.gtk.x86_6.0_org.eclipse.nls.html.txt [...] > Markus only updated the tag for doc.isv plugin. And for some reason the tag on > doc.user plugin has not been updated in the map file by the auto-tagging > scripts. Deepak, can you summarize what is the net effect of these two observations ? How exactly do they affect the quality of the bits ? That would help us assess the damage. > Though the missing doc problem should have been resolved (I have not verified > this though). > http://download.eclipse.org/eclipse/downloads/drops/I20111208-1305/directory.txt > - this shows that the v20111208-1301 tag was used for doc.isv plugin. Jay, please verify against an integration build whether all our changes are intact. Thanks.
(In reply to comment #43) > Deepak, can you summarize what is the net effect of these two observations ? > How exactly do they affect the quality of the bits ? That would help us > assess the damage. Only minor changes related to HTML markup should be missing from the build in doc.user plugin. The latest build - I20111208-1305 - should contain all the documentation that needs to be there. I understand Jay will verify the actual contents. => The latest build should be good.
(In reply to comment #44) > => The latest build should be good. Initial tests from JDT/Core are in agreement. Jay will confirm shortly.
(In reply to comment #43) > Jay, please verify against an integration build whether all our changes > are intact. Thanks. I tested the latest 3.8 build (I20111208-1305) for changes made in doc.isv and doc.user plug-ins. Here is what I find: doc.isv (plug-in version v20111208-1301) ------- I can see the last set of changes (comment# 34) that went in to the project on the help pages. This and the up-to-date plug-in version confirm that all changes made to this project have been picked up by the latest I build. doc.user (plug-in version v20111205-0928) -------- As the version indicates, an older version of this plug-in was used for this project. Here is what it is missing (on comparison with HEAD): 1. The missing <b> tag that is causing the CHKPII error. The missing tag is causing a particular text to appear normal instead of bold. The net effect is cosmetic as most browsers would handle it gracefully. 2. A bunch of <p></p> tags were re-formatted. On the help page, this doesn't seem to have any visible effect. Syntactically, it should not cause any problem.
(In reply to comment #46) > cosmetic as most browsers would handle it gracefully. > Syntactically, it should not cause any > problem. I've verified using IE7, Firefox, and Chrome => I can see the latest doc on each of these and the missing tags don't break anything.
I tested the latest 4.2 build (I20111208-2000) for null-analysis related changes and documentation. The finding is same as what I recorded in comment #46.
(In reply to comment #41) > This looks a case study in concurrent multiple failures: > > - Malformed html [...] > For having contributed to Act 1 - Scene 1 and also to the last scene of this > drama (as of now ;-)), JDT/Core team would apologize to all. Specifically, I want to apologize for the initial pebble that I accidentally threw and which later grew to this avalanche. Well, I guess it was actually a handful of pebbles. Promised: I will never again edit HTML in a plain text editor while traveling on a bus! Promised.
Dear lord... looks like this will never end. Now we have gone back in time, see http://dev.eclipse.org/mhonarc/lists/platform-releng-dev/msg19417.html
Deepak, I think Paul and I have fixed this. The local repo on our build machine was in a bad state.
(In reply to comment #49) > Promised: I will never again edit HTML in a plain text editor while > traveling on a bus! Promised. I guess now we should start looking at the positives and lessons learned from this episode - we thoroughly tested the new build scripts - rewriting Git history can have unexpected consequences, this time we got a zombie tag which messed up the build - some of us learned that CHKPII errors can cause build failures, hopefully this will be fixed in near future - some of us also learned why we MUST verify contents of the binaries we ship, here we cannot be paranoid enough!
FYI http://download.eclipse.org/eclipse/downloads/drops/I20111209-1447/index.php - This build should be good. - Plugin versions are correct - AFAICS it includes all the doc - It should also include the fix for the last remaining CHKPII failure.
(In reply to comment #52) > (In reply to comment #49) > > Promised: I will never again edit HTML in a plain text editor while > > traveling on a bus! Promised. > > I guess now we should start looking at the positives and lessons learned from > this episode You forgot the most important ones: 1. never, ever manually tag while a build is in progress 2. never, ever manually tag if you don't know how it affects the auto-tagging
