Community
Participate
Working Groups
reverting bug 578640 Today i tested https://bugs.eclipse.org/bugs/show_bug.cgi?id=578874#c2 and found that it can have negative impact to cancel autobuild: if the user cancels a JDT build the next autobuild will be a full build, because jdt is not able to resume a canceled autobuild. With bug 578640 the auto-interrupt was elevated to a cancel. It may not what the user wants. I was not aware that there was a reason to not use autointerrupt JDT build. I think it would be better to revert that change and have a more thoughtful look from JDTs side what can be done (grace period?) in bug 578874.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.resources/+/190425
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.resources/+/191619
As you wrote "can have", is the full build happening on every next build? It is still a build that would have to finish (full or not) and only if a user cancels build which I think is fairly rare for JDT cases (I have never interrupted it manually) so initially it sounds to me like not critical enough to delay the whole simrel.
Jay, as this bug is manifested by some JDT "limitation" AFAIUC it should be your call whether to respin or not.
(In reply to Alexander Kurtakov from comment #3) > As you wrote "can have", is the full build happening on every next build? It > is still a build that would have to finish (full or not) and only if a user > cancels build which I think is fairly rare for JDT cases (I have never > interrupted it manually) so initially it sounds to me like not critical > enough to delay the whole simrel. Agree. I hardly had to cancel JDT build. But it has happened once or twice. But given that it a background job and doesn't interrupt the user experience, we can live with this, especially given how late in release cycle we are.
If you save a file during an autobuild it will now cancel the jdt build automatically (good, quick ui response). But after that the next autobuild of that project will always be a clean build (bad). For average sized projects you probably won't notice the difference. For big projects it may be annoying. The size of workspace doesn't matter. If you have a lot of small projects you won't notice the difference since only the single project will be full rebuild. It's ok for me to not respin, i just thought yesterday there would be still enough time to fix that 1 liner.
(In reply to Jörg Kubitz from comment #6) > The size of workspace doesn't matter. If you have a lot of small projects > you won't notice the difference since only the single project will be full > rebuild. > > It's ok for me to not respin, i just thought yesterday there would be still > enough time to fix that 1 liner. I tried this with the JDT workspace. Looks like it's not bad. So, I suppose the 'big' must be very big projects. Note: If we are not going ahead with the reversal, this should be mentioned in the known issues list.
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.resources/+/190425 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=1dfd03d90f986df658aeb96b2d5774aa41e333eb
I think we are also affected by this issue in Eclipse 2022-03. We are using LSP4E (https://projects.eclipse.org/projects/technology.lsp4e) and when saving a source file in Eclipse the language server sends back diagnostic updates to Eclipse which are then applied to the respective document markers via a background job by LSP4E. the execution of this job now results in canceling of all other (unrelated) IncrementalProjectBuilder jobs running at the same time. We only see this issues in Eclipse 2022-03, so it would be great if you could provide an installable patch for Eclipse 2022-03.
@Jörg: is this bug resolved now? If yes, please update the state, if not, please comment what is still pending.
*** Bug 579347 has been marked as a duplicate of this bug. ***
This bug makes the current Eclipse distribution kind of unusable. Will the fix be backported to 2022-03? If so, how can we get notified about availability of a patch?
(In reply to Sebastian Thomschke from comment #12) > This bug makes the current Eclipse distribution kind of unusable. Will the > fix be backported to 2022-03? Not from Eclipse.org, we do not ship maintenance releases anymore, due the lack of resources. If you want, you can build your own SDK with the patch or use nightly builds where it is already merged, or ask your company to participate in the SDK maintenance.
