Full build fails to create class files for a Scala project not created by plugin

[scabug]

After running a full build of a Scala project in Eclipse, the output folder does not contain class files for Scala source files. Furthermore, the plugin doesn't realize that the class files aren't there, and therefore subsequent incremental builds also fail to compile the class files. Note that class files are created correctly by an initial incremental build. Only full builds have this problem. I have diagnosed and fixed this problem, and a patch is attached to this bug.

To Reproduce:[[BR]]

1. Disable automatic incremental builds: Uncheck the menu "Project | Build Automatically"[[BR]]
2. Create a scala project and add a source file.[[BR]]
3. Configure the Java builder to scrub output folders on builds (by default this option is enabled). Find this option on the preference page: "Window | Preferences… |Java | Compiler | Building | Output folder | Scrub output folders when cleaning projects"[[BR]]
4. Clean the project: select the project in the package explorer and click the menu "Project | Clean…" Check "Clean project(s) selected below", select the new project, and click Ok.[[BR]]
5. Build the project: select the menu "Project | Build Project". (Note that this may be unnecessary if you checked the box "Start a build immediately" on the Clean dialog in the previous step.)[[BR]]
6. Check the output folder for the project. It contains no class files for Scala sources.[[BR]]

Diagnosis[[BR]]
The class files aren't there because the Java builder immediately deletes class files that were just created by the Scala compiler. The Eclipse Scala builder executes a build in two steps. First it invokes the Scala builder to compile Scala sources, and then it invokes a Java builder to compile Java sources. If the Java builder is configured to scrub output folders for full builds, it deletes the class files created by the Scala compiler. The solution is for the Scala builder to temporarily disable the "Scrub output folders" option when it invokes the Java builder. Please see the attached patch, "scala-plugin-buildall-patch.txt", which implements this solution.

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-1575?orig=1
Reporter: Dave Smith (thisisthedave)
Attachments:

• scala-plugin-buildall-patch.txt (created on Dec 10, 2008 11:01:03 PM UTC, 1735 bytes)

[scabug]

Dave Smith (thisisthedave) said:
Patch to fix failure of Eclipse plugin to create class files on a full build

[scabug]

Dave Smith (thisisthedave) said:
I just noticed that scala.tools.eclipse.Nature#configure also attempts to permanently disable the "scrub output folders" option, but this doesn't work in my environment. Stepping through the JDT code (org.eclipse.jdt.internal.core.builder.BatchImageBuilder#cleanOutputFolders), the option is always enabled for Scala projects. Is it dependent on the Eclipse version? My environment:[[BR]][[BR]]

Eclipse SDK[[BR]]
Version: 3.4.1[[BR]]
Build id: M20080911-1700[[BR]]
JDK 1.5.0.17 64-bit[[BR]]
Windows Vista 64-bit

[scabug]

Dave Smith (thisisthedave) said:
I figured out why this fails in my case but not others. I am creating my Scala projects from the command line using a Maven plugin. More generally, this problem occurs for imported Scala project not created from within Eclipse. Perhaps scala.tools.eclipse.Nature#configure doesn't run for an imported project, or the JavaNature is configured later and overwrites the scrub flag? Note that this use case would occur frequently for Lift web applications. (For example: http://liftweb.net/index.php/Hello_Darwin.)

The updated repro instructions for step 2 should be:
Create a Scala project using maven:

mvn archetype:generate -U                                     \
 -DarchetypeGroupId=net.liftweb                             \
 -DarchetypeArtifactId=lift-archetype-blank                 \
 -DarchetypeVersion=0.9                            \
 -DremoteRepositories=http://scala-tools.org/repo-releases  \
 -DgroupId=sandbox.lift.hellodarwin -DartifactId=hellodarwin
cd hellodarwin
mvn eclipse:eclipse

Import the project into Eclipse (File | Import | Existing Projects into Workspace... Click Next. Browse for the hellodarwin folder you just created, click Ok, click Finish.)

[scabug]

Dave Smith (thisisthedave) said:
FYI, I confirmed that importing a project doesn't trigger a breakpoint in the Nature#configure method. Also, you can see the problem by comparing the stored preferences for a plugin-created project vs an imported project.[[br]]
.settings/org.eclipse.jdt.core.prefs for an imported Scala project:

#Wed Dec 17 20:16:19 PST 2008
eclipse.preferences.version=1
org.eclipse.jdt.core.builder.cleanOutputFolder=clean

.settings/org.eclipse.jdt.core.prefs for a non-imported Scala project:

#Fri Nov 07 12:54:14 PST 2008
eclipse.preferences.version=1
org.eclipse.jdt.core.builder.cleanOutputFolder=ignore
org.eclipse.jdt.core.builder.resourceCopyExclusionFilter=*.scala

[scabug]

@milessabin said:
I'm not sure I understand why this is a plugin issue rather than a problem with the way that Maven is creating Scala projects: if it claims to programmatically create projects it ought to create the appropriate .settings/org.eclipse.jdt.core.prefs.

[scabug]

Dave Smith (thisisthedave) said:
Mostly I think it's worth fixing because the cost is low -- the patch is already provided. Does the risk of that minor change really outweigh the benefit of ensuring that imported projects work how people expect? Nevertheless, I won't be offended if you prefer to just close it as wontfix. I know how to avoid the issue, and if it becomes a real problem somebody will eventually reopen the bug.

I consider it a plugin issue because the "scrub" setting is not really a project-specific setting for Scala projects; it is a universal requirement for all Scala projects. If it were only an issue for Maven, I could understand offloading the requirement. However, it's more serious because it applies not just to Maven projects, but to any imported Scala project for which somebody forgot to package up the .settings folder. And for projects that DO properly export the settings folder, other users will unwittingly pickup the creator's other JDT prefs, including potentially unportable settings like JRE version. Also, I expect Lift projects are becoming popular and it makes sense to accommodate that user community.

[scabug]

Josh Suereth (maewlys) said:
The lift 0.9 archetype pom is NOT compatable with the recent Scala Eclipse Plugin. You need to update the maven-eclipse-plugin configuration section to look like the following:

      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-eclipse-plugin</artifactId>
        <configuration>
          <downloadSources>true</downloadSources>
          <excludes>
            <exclude>org.scala-lang:scala-library</exclude>
          </excludes>
          <buildcommands>
            <buildcommand>ch.epfl.lamp.sdt.core.scalabuilder</buildcommand>
          </buildcommands>
          <additionalProjectnatures>
            <projectnature>ch.epfl.lamp.sdt.core.scalanature</projectnature>
          </additionalProjectnatures>
          <classpathContainers>
            <classpathContainer>org.eclipse.jdt.launching.JRE_CONTAINER</classpathContainer>
            <classpathContainer>ch.epfl.lamp.sdt.launching.SCALA_CONTAINER</classpathContainer>
          </classpathContainers>
        </configuration>
      </plugin>

If there's still an issue (I haven't had time to test) make sure you remove the java builder from your project.

I'm looking into integrating with the maven-eclipse-plugin, but this is coming in the future. For now I recommend using Q4e or m2e to manage maven dependencies, as the maven-eclipse-plugin does not run the appropriate code when adding scala natures.

[scabug]

@milessabin said:
Fixed in r17033. Using AspectJ allows the behaviour of the JavaBuilder to be controlled much more precisely, making the per project .settings redundant.