F4 launches old version of project when build fails

[iinozemtsev]

JDT's default behavior in this case is to prompt about build errors and ask whether it is ok to launch. Since Java projects just a bunch of class files, it may cause errors in runtime, however in case of Fantom, it's all or nothing – we either have a new pod without errors, or a previously built pod. So I think a prompt message should just inform that there are build errors and launch is terminated.

[iinozemtsev]

Others options to consider:

• clear project output folder before build
• clear project output folder if build contains errors

[SlimerDude]

Hi Ivan, first of all, thanks for the quick turnaround on this issue. Secondly, um, sorry to say but I have problems with it! If I read the code below correctly (from the commit), it deletes all files in the output folder:

loc := project.javaProject.getOutputLocation
f := ResourcesPlugin.getWorkspace.getRoot.getFolder(loc)
f.refreshLocal(IResource.DEPTH_INFINITE, null);
f.members.each |IResource r|{ r.delete(true, null) }

So I'm using a new F4 build that incorporates this change...

Problem 1

I have the Java default output folder pointing to my Fantom work environment so I may keep all my home built pods separate to those in the Fantom installation.

So when clearOutFolder() runs it deletes all pods in my Fantom workDir. That includes all the pods I happened to have in my custom Env.

Problem 2

All my F4 projects have their Java output folder pointing to the same directory (the work dir), so when clearOutFolder() runs and deletes all the pods, it prompts all the other projects to rebuild too (because their output pod is missing).

It is not uncommon for me to have 10 F4 projects open, all dependent on other, so when they all start re-building, it can take some time.

Problem 3

The rebuilding of pods is continuous until the compilation error is fixed.

With the output dir cleansed, and the projects refreshed, they re-build themselves. But because that same compilation error is still there, the output dir is deleted again, the projects refreshed, and the compilation error is still there....

It's a vicious circle that repeats itself, and hogs the processor, until the compilation error is fixed.

Problem 4

On each rebuild I get an error prompt / pop up in F4 with the following stacktrace. This makes it difficult to fix the compilation error, because I'm too busy closing closing down these error popup windows!

Errors running builder 'Script Builder' on project 'Dekxa App'.
sys::UnknownSlotErr: sys::Err.toJava
    at fan.sys.UnknownSlotErr.make(UnknownSlotErr.java:25)
    at fan.sys.UnknownSlotErr.make(UnknownSlotErr.java:22)
    at fan.sys.ClassType.slot(ClassType.java:104)
    at fan.sys.FanObj.doTrap(FanObj.java:187)
    at fan.sys.FanObj.trap(FanObj.java:179)
    at fan.f4core.LogUtil.logErr(LogUtil.fan:10)
    at fan.f4builder.CompileFan.clearOutFolder(CompileFan.fan:222)
    at fan.f4builder.CompileFan.buildPod(CompileFan.fan:175)
    at fan.f4builder.CompileFan.build(CompileFan.fan:69)
    at org.eclipse.dltk.internal.core.builder.ScriptBuilder.incrementalBuild(ScriptBuilder.java:550)
    at org.eclipse.dltk.internal.core.builder.ScriptBuilder.build(ScriptBuilder.java:176)
    at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239)
    at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295)
    at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351)
    at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374)
    at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
    at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

I think this could be because my java output folder is a linked resource. In my .project I have the following:

<linkedResources>
    <link>
        <name>workDir</name>
        <type>2</type>
        <location>C:/Repositories/Fantom</location>
    </link>
</linkedResources>

I create it using the advanced options in the 'New Folder' dialog box. I then set the java output folder to this linked resource, e.g. in an F4 project called Pillow it would be Pillow/workDir.

Fixes

By deleting just the project's pod (and not the entire directory), that would probably fix problems 1 & 2. For problem 3 you'd need some kind of recursion detection, or flag if an error rebuild has already happened. I'm not too sure what causes the error in problem 4.

Your initial idea of a aborting launches with a prompt is quite a good one, but I expect also difficult to implement.

I know that Tom gave quite a public outcry over this issue on the Fantom forum, but I don't see it as such a big deal myself. Once you know that a pod only gets re-build when it's error free, it's obvious! I think people have just become spoiled by the incremental builds eclipse does for Java!

I'm probably going to remove this change from my local F4 build because I find it quite disruptive. (The other fixes are good though! Thanks!)