Community
Participate
Working Groups
I'm currently migrating an Xtext project from 2.0 to 2.2.1 (originally 0.7.x). In one of the sub-projects the xtend compiler stopped to work at all: - no errors / warnings - nothing in the logs - no java files generated I can't even tell if there *is* an xtend compiler at all. However, in other sub-projects with very similar setup the xtend compiler works OK. I've experimented with - xtend compiler preferences like output path - originally the project used the org.eclipse.xtend.shared.ui.xtendBuilder, but now this builder is shown as "Missing builder". May I assume that invoking the xtend compiler is handled by the xtext builder? None of my experiments seemed to help. Any hints on how to debug this?? Maybe I'm doing something stupid, but then the compiler/builder should tell me. FWIW, for full builds I (try to) use tycho, but inside the IDE everything is treated as a normal Xtext project (including all the natures, builders, Plug-in Dependencies etc.). I even tried removing the maven nature but to no avail.
You need to add the Xtext nature. "org.eclipse.xtend.shared.ui.xtendBuilder" is the id of the old (Xtend 1) builder.
(In reply to comment #1) > You need to add the Xtext nature. I have this: <nature>org.eclipse.xtext.ui.shared.xtextNature</nature> What should I add? > "org.eclipse.xtend.shared.ui.xtendBuilder" is the id of the old (Xtend 1) > builder. That's what I figured. Just wanted to be sure.
Just to make sure it's not an eclipse issue: Other builders on that project are still running?
(In reply to comment #3) > Just to make sure it's not an eclipse issue: Other builders on that project are > still running? Yep, the PDE builders, e.g., run OK.
I've never seens this before. Removing and re-adding the nature did not make any difference, did it? You may want to dive into XtextBuilder#build to see whether it's actually triggered for the offending project.
(In reply to comment #5) > I've never seens this before. Removing and re-adding the nature did not make > any difference, did it? I didn't try, but I restarted Eclipse (several times). Would remove/adding the nature perform any reset that's not performed at Eclipse restart? > You may want to dive into XtextBuilder#build to see whether it's actually > triggered for the offending project. I'll do it the very first thing Monday morning. Are there any additional tracing options I could use? thanks
(In reply to comment #6) > (In reply to comment #5) > > I've never seens this before. Removing and re-adding the nature did not make > > any difference, did it? > > I didn't try, but I restarted Eclipse (several times). > Would remove/adding the nature perform any reset that's not performed > at Eclipse restart? Re-adding the nature may re-activate the builder and the appropriate command. A restart wont' help for that. > > > You may want to dive into XtextBuilder#build to see whether it's actually > > triggered for the offending project. > > I'll do it the very first thing Monday morning. > Are there any additional tracing options I could use? > Unfortunately not. Is the problem reproducable if you import the project into another Eclipse WS?
(In reply to comment #7) > (In reply to comment #6) > > Would remove/adding the nature perform any reset that's not performed > > at Eclipse restart? > > Re-adding the nature may re-activate the builder and the appropriate command. A > restart wont' help for that. Really? But wouldn't reading .project after an Eclipse start do the same initialization? Where else would broken builder configuration be stored?? Anyway, I'll also try the re-adding of natures on Monday. > Is the problem reproducable if you import the project into another Eclipse WS? It occurred in two different workspaces. Still I can't 100% rule out that I did the same disastrous step in both workspaces. More to try on Monday.
OK, once I started debugging I went all the way down, which actually revealed the mystery: The builder was invoked but the filtered deltas where empty. On closer look this happened because .classpath contained a bogus entry 'including="**/*.java"'. Looking at the file history it looks like m2e "donated" this entry. I'll recheck this in a minute. So the Xtext builder is not to blame. OTOH this looks like a situation that others can run into, too, and they will be equally irritated. Therefor, I'd like to suggest better handling of this situation. I'm changing this bug to the following enhancement request: The UI should vizualize when an xtend file is not on the classpath. For comparison: The JDT has a specific variant of the "J" icon (with the letter printed in outline) that serves exactly this purpose: show that a file is recognized as a Java file but that it is not on the classpath. The same approach could be used for xtend, too. Showing this information per file is relevant, because - as in my case - a file my reside in a source folder of the classpath, yet the file itself can be excluded from the classpath by a filter. In this case the user cannot see that this file will be excluded from compilation.
