Community
Participate
Working Groups
Version: 2019-06 M2 (4.12.0M2) Build id: 20190509-1623 Eclipse Enterprise package I have Project > Build Immediately on as I have for years. I'll usually start up Eclipse and let it sit for a minute or two to make sure it has loaded everything and indexed everything and brought everything up-to-date so that I can develop in peace without it making me wait for system upkeep. Now in version 2019-06 M2 after Eclipse calms down, when I touch it suddenly it springs to life and makes me wait again. For example, maybe I'll just click on an open file. Or maybe I'll click on a project in Project Explorer. It especially happens if I click on a project and hit `Ctrl+Shift+3` to commit changes to the Git repository. Suddenly Eclipse tells me to wait because other things are going on, and it initializes tooling, it checks the file system for changes, and then decides it wants to rebuild half my projects (which can take even a minute or more!)—when I only asked it to commit files to SCM, which has nothing to do with compiling. Oddly the projects were compiled and up-to-date when I last closed down Eclipse, so why is it rebuilding them? If it needed to rebuild projects, why didn't it do that when it started up, instead of waiting until I needed to do some action completely unrelated to building? And if "build automatically" was on when I last had Eclipse open, and no changes were made to the file system after Eclipse was shut down, why is Eclipse trying to build things again? I really don't remember Eclipse behaving like this pre 2019-06, but maybe I'm just now noticing this.
It would be interesting to know what is the first activity after click that triggers all updating & building. The commit scenario should probably be reported to EGit, maybe they trigger a workspace refresh and that triggers a workspace build? I suspect that JDT is only reacting to s.o. else's request, but obviously I cannot prove that. FWIW: in my JDT development workspace Eclipse is completely calm after initializations (e.g., by oomph) are done, and when I start clicking here and there. This also reminds me of constant push in Platform to perform more initialization lazily, rather than during start-up. Some changes in this field could possibly be the cause for the change in behavior you are observing. We "just" need to find out, what exactly triggers it.
It is always trying to "initialize JavaScript tooling" and then rebuild the project when I try to commit changes for the first time using `Ctrl+Shift+3`. This is for a workspace that has been opened and been allowed to sit for five minutes or so with absolutely no modifications.
(In reply to Garret Wilson from comment #2) > It is always trying to "initialize JavaScript tooling" Is that from WebTools or do you use Wild Web Developer, or still s.t. else? Please move the bug to them for investigation.
> Is that from WebTools or do you use Wild Web Developer, or still s.t. else? I don't understand the question. I am using the pure, unadulterated Eclipse IDE for Enterprise Java Developers 2019-06 M2 found here: https://www.eclipse.org/downloads/packages/release/2019-06/m2 https://www.eclipse.org/downloads/packages/release/2019-06/m2/eclipse-ide-enterprise-java-developers I don't even know what "JavaScript tooling" is. It is a message that appears (along with many others; I mentioned some of them) in the Eclipse task bar as it decides that it needs to do a bunch of stuff, including building my project (when it was already built).
> FWIW: in my JDT development workspace Eclipse is completely calm after initializations (e.g., by oomph) are done, and when I start clicking here and there. I am not using Oomph because of problems I reported elsewhere (namely, placing some required workspace-related information on the local system rather than in the workspace itself, preventing me from installing the Eclipse workspace on a portable drive and simply installing the Eclipse executable on different computers). I wonder if you are using M2E and EGit (which come bundled with the Enterprise package I mentioned in a previous comment).
> Please move the bug to them for investigation. It always occurs when I hit `Ctrl+Shift+3` (`Ctrl+Shift+#`) to perform a Git commit. So I guess I'll move the bug to JGit to see what they think.
Actually I suppose this should be EGit, which I believe is the Eclipse integration built on top of JGit, the library.
I have never seen this, but I also don't use the Javascript edition of Eclipse. Can you please open Windows > Preferences > Keys and type "Ctrl+#", "Ctrl+Shift+3" etc. into the filter to see if there is _another_ conflicting key binding than just the egit commit command (I only see the commit command on Ctrl+#)?
> I also don't use the Javascript edition of Eclipse. What is the "JavaScript edition of Eclipse"? I'm using the Enterprise package, which I linked to in this ticket. > Can you please open Windows > Preferences > Keys … The only thing mapped to `Ctrl+#` is "Commit...", which is what I'm trying to do! But let me ask you this: how can I press `Ctrl+#` without pressing `Ctrl+Shift+3`?? I note that "Open Source" is mapped to `Ctrl+Shift+3` when debugging JavaScript. (But I'm not referring to debugging mode. And I'm not editing JavaScript.) Why does one say `Ctrl+Shift+3` and the other `Ctrl+#`? Aren't those the same thing? But anyway, **this key mapping thing is irrelevant and a wild goose chase**. The exact same thing happens when I right click on a project and select Team > Commit…, so the mapped key combination should have nothing to do with it. Before bringing up the commit dialog it says various things like "Initializing JavaScript tooling" and then it rebuilds portions of my project (even when my project should have already been built!). Even if you don't understand what "JavaScript tooling" means (I don't either), don't let that distract you from the rebuilding, which takes a significant amount of time and is what this ticket indicates in the title. Why is it rebuilding my project when I just want to commit? Note that I am using the commit dialog instead of the staging view. (See Preference > Team > Git > Committing.)
(In reply to Garret Wilson from comment #9) > > I also don't use the Javascript edition of Eclipse. > > What is the "JavaScript edition of Eclipse"? > > I'm using the Enterprise package, which I linked to in this ticket. As per the package details [1] this implies you have these: - org.eclipse.wst.jsdt.feature - org.eclipse.wst.jsdt.chromium.debug.feature ("JavaScript Development Tools" [2]) [1] https://www.eclipse.org/downloads/packages/release/2019-06/m2/eclipse-ide-enterprise-java-developers [2] https://www.eclipse.org/webtools/jsdt/
Today I opened up Eclipse 2019-06 M3. I opened up a JUnit 5 unit test and added a single method. (It could hardly be simplier: it is just a test of `toString()` and a related method.) I hit Ctrl+F11 to run the unit test. Suddenly Eclipse decides that it needs to rebuild about half my projects. Again I wonder: * If I have "build automatically" turned on, why wasn't all this stuff built when I closed down Eclipse the last time? * Even if something new needed to be built, why didn't Eclipse build it when I saved the unit test, and not much later when I hit `Ctrl+11`? This is not a key mapping issue. I suspect it has nothing to do with EGit. It feels to me like an Eclipse problem of no longer building automatically when it should, and trying lazily build later. (But even that doesn't explain why suddenly it feels it has to rebuild so much, when I only changed a single unit test method.)
Now I'm using Eclipse 2019-06 RC1, and this is definitely a problem. I open Eclipse, I leave it open for maybe even five or 10 minutes, and then I work on a unit test, as I described earlier. I finish the unit test method (just two or three lines) and try to run it. Suddenly Eclipse decides it needs to rebuild things—lots of things—and I have to wait maybe 10 seconds or more before the unit test will even run. If I have "build automatic" turned on, I expect it it to build automatically as it always has done, not just when I try to run a unit tests. And if the whole thing was built when I close Eclipse, I don't expect Eclipse to change its mind when I restart it and decide, "well, I know it was built before, but now I think it's not built anymore so I'm going to rebuild stuff". The things I'm describing aren't unique to EGit, and the new way to reproduce it doesn't even involve EGit. I think this is a regression overall on Eclipse about building things automatically, so I'm moving it back to JDT. Stephan mentioned Eclipse is trying to do lots of things at the last minute now, but the whole point of building automatically is building _not_ at the last minute so that it will be already built _when I try to do something interesting_. So if this was done intentionally, it went to far, and is now defeating the purpose of "build automatically".
@Garret, I see several options how we can make progress here, all of which boil down to: we first need to identify what triggers those unwanted builds. (1) You could provide an example project that is sufficient to reproduce the problem in a plain Eclipse SDK, i.e. no m2e not EGit etc. When we have that we know we have a problem in JDT (or Platform/Resources) and can start investigating. (2) Alternatively you could provide stack dumps from the point in time when Eclipse starts building. (3) You could also run Eclipse with debug tracing enabled, specifically all options below org.eclipse.core.resource/build should we interesting. See e.g., https://wiki.eclipse.org/FAQ_How_do_I_use_the_platform_debug_tracing_facility#Turning_on_debug_tracing The options can be found in a launch configuration of type Eclipse Application, on tab Tracing. Unfortunately there is no option how we can identify the problem on your machine without your help.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
