Javadoc build failure #484
Comments
|
Last successful execution is https://download.eclipse.org/eclipse/downloads/drops4/I20230316-1800/ So we have regression between I20230316-1800 and I20230320-0330. I don't see any breaking changes in JDT UI code here, so it must be something related to recent platform / releng activities. |
|
See "similar" issue eclipse-platform/eclipse.platform.common#18 and fix https://github.com/eclipse-platform/eclipse.platform.common/pull/19/files. |
|
I've added https://github.com/eclipse-platform/.github/wiki/Javadoc-validation to start documenting how all that works. @sravanlakkimsetti : would be great if you could fix the wiki above so other people can also understand how that javadoc build works and if you could give here a hint what is broken today n platform. |
|
@iloveeclipse I can see 1 possible cause. org.eclipse.core.runtime is used in jdt.ui. I see that o.e.core.runtime updated to java 17 but the jdt.ui plugins that use o.e.core.runtime are set at java-11. I think we need to update jdt.ui bundles to java-17. |
|
@sravanlakkimsetti : thanks, that is surely not only one place where JDT (which is still on Java 11) uses platform that is on Java 17. But this implies that somewhere we run some task on Java 11 runtime that is unable to read Java 17 class files - where would be this output? Is this "cut out" from jdt.doc.isv.javadoc.txt ? I would love to see this build chain explained in the wiki. Who starts which process in which script and how that generates at the end the xyz.javadoc.txt files. |
|
I jotted down some points on how build is triggered in the wiki page. |
|
@sravanlakkimsetti : thanks. Where, in which log are we supposed to see this output: |
|
this is the exact line where we execute javadoc and generate the log doc.bin.log. The doc.bin.log is renamed here the rename happens during |
|
@sravanlakkimsetti : yes, I see it, but in which log file in the SDK build do we see the output from the echo task that runs 40 lines above |
|
we are running ant with The commandline options are specified in https://github.com/eclipse-platform/eclipse.platform.common/blob/54455a117960237d69a9d840e61872641cafdaaa/bundles/org.eclipse.jdt.doc.isv/pom.xml#L102 |
|
Arrgh, OK, I will check that. Any idea why |
|
FWIW, the process is too cumbersome and if there is agreement to move javadoc to separate bundles that contain only the javadoc I'm sure that we can craft something far easier to manage. Ideally, having one such bundle per git repo so javadoc errors are flagged even by verification builds. @laeubi already asked and tried things in that area for equinox and platform. |
|
The quiet was added in eclipse-platform/eclipse.platform.common@0b511f5 as a "follow up" on https://bugs.eclipse.org/bugs/show_bug.cgi?id=443771 with no further comments. I would propose to enable it on JDT to see how bad is "no quiet" mode and if we will see some more info there. |
|
Actually tycho has a "document bundle" plugin, that seems to work towards the direction of having an "eclipse-javadoc-tool", but it is / was not really used, so if there are some demands I'm open to revive / modernize the plugin but I'm not very familiar with the current "doc-builds" and what are the expected outcomes are. |
I wonder why do we provide that javadoc at all? |
|
@laeubi : is there any way to say tycho to run on Java 17 in https://github.com/eclipse-platform/eclipse.platform.common/blob/54455a117960237d69a9d840e61872641cafdaaa/bundles/org.eclipse.jdt.doc.isv/pom.xml#L87 ? Or is this already using Java 17? |
|
Tycho always require Java 17 to run so this usually should already use Java 17, but the eclipse run itself calls ant so I'm not sure if/how there might be a different setting for that, there is a file in that folder that seems to configure some jdt options (guessing by name): |
|
By the way as far as I know this does not only generates javadoc but also the extension point docs and alike... |
|
I've created eclipse-platform/.github#108. |
- Remove "-quiet" ant argument from org.eclipse.jdt.doc.isv - print java.home additionally to used javadocExecutable See eclipse-jdt/eclipse.jdt.ui#484
- Remove "-quiet" ant argument from org.eclipse.jdt.doc.isv - print java.home additionally to used javadocExecutable See eclipse-jdt/eclipse.jdt.ui#484
|
@sravanlakkimsetti : I don't see anything in any log file that would indicate the "echo" from https://github.com/eclipse-platform/eclipse.platform.common/pull/128/files is there. I'm looking for example for string
So I assume the pom change has no effect => the javadoc build is triggered from somewhere else? |
|
I see the echo statements in mb220_buildSdkPatch.sh.log. Please refer to line numbers 30550 and 30551. build for org.eclipse.jdt.doc.isv starts at 28960 and ends at 31073. |
|
@sravanlakkimsetti : interesting, I was looking at the first page, but missed completely https://download.eclipse.org/eclipse/downloads/drops4/I20230321-1800/buildlogs.php. Unfortunately nothing interesting shown there, except that the tooling used same Java 17 version already for 4.27 and last successful 4.28 build without any troubles. I now assume something is wrong with the classpath provided to the javadoc, something that breaks regular expression parser there etc. |
|
Looks like moving JDT UI bundles to Java 17 via #493 fixed gazillions of errors related to jdt.ui. Remaining one will be probably fixed either via eclipse-jdt/eclipse.jdt.debug#210 or by ant / debug bundles updates, I will try to do this today. |
|
I have touched doc bundles via https://ci.eclipse.org/releng/job/Touch_doc_bundles/62/ and will trigger I-build now so we can see the exact state of the issue. |
I've added this to the wiki: https://github.com/eclipse-platform/.github/wiki/Javadoc-validation Can you please add explanation why, in which cases is this needed? |
Adding the explanation now. A bit lengthy will take some time. |
|
I have no time to investigate it further, especially there is no explanation how one can run the build only for the doc bundles without the rest of SDK. => workaround to build only subset of API reference for M1 (that at least produces non-empty doc bundles and I see no errors anymore opening help in built SDK): |
Interestingly, even if my local SDK build succeeded, SDK build still has same problem. So something is missing, even if the doc bundles were touched: eclipse-platform/eclipse.platform.common@df307d9 Log file from this build is https://download.eclipse.org/eclipse/downloads/drops4/I20230405-1800/buildlogs/mb220_buildSdkPatch.sh.log |
I was wrong. My local build is still broken in same way like "official" one, but it is now less broken as the state I saw before with gazillions of JDT UI errors, so I've assumed it is OK, which is not. => will revert last change via #484 |
|
This is the arguments file that the javadoc command executes: And with exact that list in my local SDK build directory tree I don't see any errors. BUT! If I change I see exact the error we see on the "official" build: What is really strange, because the externaltools/target/classes directory IS there after SDK build and the classpath I've extracted from ant log file works after the build but not during the build. And in fact, it looks like the externaltools are compiled after we build javadocs!!! I see this output AFTER the build fails! |
|
And here is the order that maven prints at beginning: Note: javadoc requires built code of external tools bundle that is compiled after javadoc bundles. |
|
If |
|
So was there a tycho / maven change that changed the order of dependencies? |
This makes sure the org.eclipse.core.externaltools is built before the javadoc is executed, so it's target/classes directory is not empty and javadoc sees the required classes used by JDT. See eclipse-jdt/eclipse.jdt.ui#484
|
You see additional dependencies are defined here: if there is no dependency, this means the project can be build any time before/after or even in parallel. Also if I understand one needs to "touch" files to have things changed, so maybe this problem exits longer but was not noticed, or some dependency changed and the order changed therefore slightly... |
|
I've set eclipse-platform/eclipse.platform.common#136 that adds this dependency. But thinking more, all of the bundles we refer via target/classes, starting with this line should be on the pom file dependencies list? |
At best yes... I have investigated about the details how this works and think it can also work on the compiles jars, but currently it all very specific to a workspace, and compiled class files in a folder, I hope to find some time to optimize here and move stuff from ant->maven but that probably will be more ongoing work than happening tomorrow. |
This makes sure the org.eclipse.core.externaltools is built before the javadoc is executed, so it's target/classes directory is not empty and javadoc sees the required classes used by JDT. See eclipse-jdt/eclipse.jdt.ui#484
This makes sure the dependencies are built before the javadoc is executed, so it's target/classes directory is not empty and javadoc sees the required classes used by JDT. See eclipse-jdt/eclipse.jdt.ui#484
This makes sure the dependencies are built before the javadoc is executed, so it's target/classes directory is not empty and javadoc sees the required classes used by JDT. See eclipse-jdt/eclipse.jdt.ui#484
|
Note: I've added more dependencies to maven via eclipse-platform/eclipse.platform.common#139 |
In latest I-build javadoc build fails with the issues shown at https://download.eclipse.org/eclipse/downloads/drops4/I20230320-0330/compilelogs/jdt.doc.isv.javadoc.txt
The text was updated successfully, but these errors were encountered: