source files are not refreshed by eclipse (and scala IDE)

[Maxime Lévesque]

Hi there, I'm a new Scala IDE user,
When I pull code changes from Git,
ScalaIDE is often looking for files that have been deleted,
(see exception below) so I get a file not found... but the
some times a refresh fixes it, sometimes I need to restart eclipse,
it looks like this time around I'll need to wipe the worspace and re import it
into eclipse..... what a drag.... Is there a setting where I can set :

  refresh means refresh = true

(there's an auto refresh setting on the workspace, I've enabled it, but
I am clueless as to what is being refreshed exactly, cause my
file deletions are not being refreshed...)

Is this a known issue ?
Am I alone in the word experiencing this ?

Thanks

org.eclipse.core.runtime.CoreException: File not found: D:\dev\faw1\core\src\main\scala\com\jaxi\lib\DD.scala.
at org.eclipse.core.internal.filesystem.Policy.error(Policy.java:55)
at org.eclipse.core.internal.filesystem.local.LocalFile.openInputStream(LocalFile.java:371)
at org.eclipse.core.internal.localstore.FileSystemResourceManager.read(FileSystemResourceManager.java:702)
at org.eclipse.core.internal.resources.File.getContents(File.java:293)
at org.eclipse.jdt.internal.core.util.Util.getResourceContentsAsCharArray(Util.java:1186)
at org.eclipse.jdt.internal.core.CompilationUnit.getContents(CompilationUnit.java:649)
at scala.tools.eclipse.javaelements.ScalaCompilationUnit$class.createSourceFile(ScalaCompilationUnit.scala:57)
at scala.tools.eclipse.javaelements.ScalaSourceFile.createSourceFile(ScalaSourceFile.scala:39)
at scala.tools.eclipse.ScalaPresentationCompiler$$anon$1.default(ScalaPresentationCompiler.scala:41)
at scala.tools.eclipse.ScalaPresentationCompiler$$anon$1.default(ScalaPresentationCompiler.scala:39)
at scala.collection.MapLike$class.apply(MapLike.scala:135)
at scala.collection.mutable.HashMap.apply(HashMap.scala:43)
at scala.tools.eclipse.ScalaPresentationCompiler.withSourceFile(ScalaPresentationCompiler.scala:66)
at scala.tools.eclipse.ScalaProject$$anonfun$withSourceFile$1.apply(ScalaProject.scala:459)
at scala.tools.eclipse.ScalaProject$$anonfun$withSourceFile$1.apply(ScalaProject.scala:458)
at scala.tools.eclipse.ScalaProject$$anonfun$withPresentationCompiler$1.apply(ScalaProject.scala:452)
at scala.tools.eclipse.ScalaProject$$anonfun$withPresentationCompiler$1.apply(ScalaProject.scala:451)
at scala.tools.eclipse.util.Cached$class.apply(Cached.scala:52)
at scala.tools.eclipse.ScalaProject$$anon$1.apply(ScalaProject.scala:47)
at scala.tools.eclipse.ScalaProject.withPresentationCompiler(ScalaProject.scala:451)
at scala.tools.eclipse.ScalaProject.withSourceFile(ScalaProject.scala:460)
at scala.tools.eclipse.javaelements.ScalaCompilationUnit$class.withSourceFile(ScalaCompilationUnit.scala:46)
at scala.tools.eclipse.javaelements.ScalaSourceFile.withSourceFile(ScalaSourceFile.scala:39)
at scala.tools.eclipse.javaelements.ScalaCompilationUnit$class.buildStructure(ScalaCompilationUnit.scala:89)
at scala.tools.eclipse.javaelements.ScalaSourceFile.buildStructure(ScalaSourceFile.scala:39)
at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:258)
at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:515)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:252)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:238)
at org.eclipse.jdt.internal.core.JavaElement.getChildren(JavaElement.java:193)
at org.eclipse.jdt.internal.core.JavaElement.getChildrenOfType(JavaElement.java:207)
at org.eclipse.jdt.internal.core.CompilationUnit.getTypes(CompilationUnit.java:920)
at org.eclipse.jdt.internal.corext.refactoring.util.JavaElementUtil.getMainType(JavaElementUtil.java:91)
at org.eclipse.jdt.internal.corext.refactoring.RefactoringAvailabilityTester.getSingleSelectedType(RefactoringAvailabilityTester.java:157)
at org.eclipse.jdt.ui.actions.ExtractClassAction.selectionChanged(ExtractClassAction.java:81)
at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchSelectionChanged(SelectionDispatchAction.java:262)
at org.eclipse.jdt.ui.actions.SelectionDispatchAction.selectionChanged(SelectionDispatchAction.java:257)
at org.eclipse.jface.viewers.Viewer$2.run(Viewer.java:162)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:49)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
at org.eclipse.jface.viewers.Viewer.fireSelectionChanged(Viewer.java:160)
at org.eclipse.jface.viewers.StructuredViewer.updateSelection(StructuredViewer.java:2162)
at org.eclipse.jface.viewers.StructuredViewer.handleSelect(StructuredViewer.java:1190)
at org.eclipse.jface.viewers.StructuredViewer$4.widgetSelected(StructuredViewer.java:1220)
at org.eclipse.jface.util.OpenStrategy.fireSelectionEvent(OpenStrategy.java:228)
at org.eclipse.jface.util.OpenStrategy.access$4(OpenStrategy.java:222)
at org.eclipse.jface.util.OpenStrategy$1.handleEvent(OpenStrategy.java:389)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4066)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3657)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2640)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438)
at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:620)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:575)
at org.eclipse.equinox.launcher.Main.run(Main.java:1408)
Caused by: java.io.FileNotFoundException: D:\dev\faw1\core\src\main\scala\com\jaxi\lib\DD.scala (Le chemin d’accès spécifié est introuvable)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:120)
at org.eclipse.core.internal.filesystem.local.LocalFile.openInputStream(LocalFile.java:362)
... 70 more

[Viktor Hedefalk]

I definitely recognize the problem. Refresh has always been
problematic in Eclipse. For some reason refresh with say F5 has not
always been the same as refreshing with the project context menu (even
though it says so).

I use MercurialEclipse to do stuff with hg from within Eclipse
sometimes and then I think the plugin automatically tells Eclipse to
refresh when I checkout a new changeset. Maybe the git plugin does the
same and can be some kind of temporary workaround for you? Well, I
recognize that if you're used to cli you probably want to stay with
cli, but just a thought.

The workspace setting you mentioned, is that the "Refresh using native
hooks or polling"? I'm on OS X so I figure that could maybe work a lot
better than doing manual refreshs. Hadn't seen that so thanks!

Anyway, I have had similar problems so I'm really interested in a solution too!

Thanks,
Viktor

2011/9/22 Maxime Lévesque <maxime....@gmail.com>:

[Francois]

On 22/09/2011 02:40, Maxime Lévesque wrote:
>
> Hi there, I'm a new Scala IDE user,
> When I pull code changes from Git,
> ScalaIDE is often looking for files that have been deleted,
> (see exception below) so I get a file not found... but the
> some times a refresh fixes it, sometimes I need to restart eclipse,
> it looks like this time around I'll need to wipe the worspace and re
> import it
> into eclipse..... what a drag.... Is there a setting where I can set :
>
> refresh means refresh = true
>
> (there's an auto refresh setting on the workspace, I've enabled it, but
> I am clueless as to what is being refreshed exactly, cause my
> file deletions are not being refreshed...)
>
> Is this a known issue ?
> Am I alone in the word experiencing this ?
>

I don't know if you use the Git plugin for eclipse or the command line,
but for a time I used to only use the command line without eclipse
plugin, and that lead to a lot of synchronisation problems. Now, I sill
use the command line most of the time, but the Eclipse Git plugin does
see most of the updates correctly.

Hope it helps,

--
Francois ARMAND
http://fanf42.blogspot.com
http://www.normation.com

[Viktor Hedefalk]

Did some googling now:

http://stackoverflow.com/questions/1212633/can-eclipse-refresh-resources-automatically

From this:

"This issue will be fixed in Eclipse 3.7 (Indigo). While "Refresh
Automatically" does eventually bring resources back into sync, the
refresh hook only exists for Windows, so on Linux and Mac OS it has to
poll the filesystem periodically."

I think I understand the following:

The setting was called "Refresh Automatically" pre Indigo and only
works nicely in Windows. In OS X and GNU/Linux it uses polling instead
which is heavy-weight and probably glitches a lot. In Indigo it's
renamed "Refresh using native hooks or polling" and works the same.
But there is also a new light weight thing called "Refresh on access"
that checks if a file is in sync when accessed.

I guess than that you are on Galileo or earlier and probably don't
have this setting, but maybe that light weight variant actually works?
I'm gonna try it at least and report back.

Cheers,
Viktor

[Francois]

On 22/09/2011 12:08, Bryan Hunt wrote:
> Not to detract from the original issue, but...
>
> Having used Eclipse for much of the past 10 years - like many of
> my colleagues and friends, we have chosen to eschew integrated VCS
> plugins.
>
> They just never work properly, better to use the command line.

That's exaclty what I'm doing (use git command line), but having said to
Eclipse "that's a project under Git" make the synchronisation between FS
and what is displayed by Eclipse disappeared. Well, and it also display
the current branch for the project in Eclipse, it's a cool little
addition ;)

[Maxime Lévesque]

For the record, I'm using Helios, just because the ScalaIDE site says that Indigo is experimental.
I'm using command line Git on Mingw32 (windows). I did try the eclipse Git plugin (EGit) but
gave up after 10 minues.

I'll switch to any version of eclipse that has a decent refresh, it's a critical function for anyone
that uses Git. François, which version of eclipse are you using, and what is the exact plugin
(and version of it) that makes the sycn problem disapear ?


Good to know it's a known issue, thanks for the group therapy guys ;-)

2011/9/22 Francois <fan...@gmail.com>

[Francois]

On 22/09/2011 15:39, Maxime Lévesque wrote:
>
> For the record, I'm using Helios, just because the ScalaIDE site says
> that Indigo is experimental.
> I'm using command line Git on Mingw32 (windows). I did try the eclipse
> Git plugin (EGit) but
> gave up after 10 minues.
>
> I'll switch to any version of eclipse that has a decent refresh, it's
> a critical function for anyone
> that uses Git. François, which version of eclipse are you using, and
> what is the exact plugin
> (and version of it) that makes the sycn problem disapear ?

I don't remember if there was a precise version of Eclipse/EGit that
make things really better, it was more an incremental amelioration.
Right now, I'm using Eclipse 3.7 (Indigo) with it's EGit version (since
in 3.7, it is included) : 1.0.0.201106090707-r

But I'm on Linux, and it may be a big difference here.

For the "critical function for anyone that uses Git", I can't agree
more... In the past, changing from a branch to another was taking years
and was not always accurate.

[ijuma]

On Thursday, 22 September 2011 14:39:18 UTC+1, Maxime Lévesque wrote:

For the record, I'm using Helios, just because the ScalaIDE site says that Indigo is experimental.

Are there known issues that affect Indigo but not Helios or is this just conservative wording? Indigo SR1 (first maintenance release) is now out and it includes support for Java 7, so it would be good to have non-experimental support for it.

Best,

Ismael

[Mirco Dotta]

Hi Ismael,

Are there known issues that affect Indigo but not Helios or is this just conservative wording? 

A little bit of the two actually :) 

On the one hand, there are currently a few issues that affect only Indigo and not Helios. On the other hand, 

it is also conservative wording because the currently thin regression test suite doesn't allow us to officially 

support Indigo. Almost everyone here at Typesafe and EPFL is using the plugin with Helios, and that's 

currently the main way the IDE is daily tested.

Indigo SR1 (first maintenance release) is now out and it includes support for Java 7, so it would be good to have non-experimental support for it.

Yes. I think one good option would be to have the future 2.1 Scala IDE plugin to target Eclipse Indigo 3.7.1+.

I think after the 2.0 release we'll have more time to discuss this in the mailing list and see what the other committers think.

Cheers,

  Mirco

---------------

Mirco Dotta

Typesafe - Enterprise-Grade Scala from the Experts 

PSE-D, 1015 Lausanne, Switzerland

Work: +41 (0)21 691 49 65

Twitter: @mircodotta

[ijuma]

Hi Mirco,

Thanks for the explanation.

On Monday, 26 September 2011 10:28:31 UTC+1, Mirco Dotta wrote:

Yes. I think one good option would be to have the future 2.1 Scala IDE plugin to target Eclipse Indigo 3.7.1+.

I think after the 2.0 release we'll have more time to discuss this in the mailing list and see what the other committers think.

Sounds like a good plan.

Best,

Ismael

[David Whittaker]

Max,

I'm using Indigo myself with the Scala IDE plugin from http://download.scala-ide.org/releases-29/2.0.0-beta.  I've got egit installed but I really only use it for diffing files between commits/branches, I've been doing everything else from the command line.  Whenever I issue a command that changes the working directory I just select the root of the project and hit f5 to refresh everything.  It's been working well for me.

2011/9/22 Maxime Lévesque <maxime....@gmail.com>

[Maxime Lévesque]

Thanks Dave, I'll give Indigo a try, I'll live with whatever bugs there are in this combination if it gives me a reliable refresh.

2011/9/27 David Whittaker <da...@iradix.com>

[ijuma]

On Tuesday, 27 September 2011 18:19:22 UTC+1, David Whittaker wrote:

I'm using Indigo myself with the Scala IDE plugin from http://download.scala-ide.org/releases-29/2.0.0-beta.  I've got egit installed but I really only use it for diffing files between commits/branches, I've been doing everything else from the command line.  Whenever I issue a command that changes the working directory I just select the root of the project and hit f5 to refresh everything.  It's been working well for me.

This sort of works, but there are times where recompilation doesn't happen as it should (using latest beta with SBT builder). Touching the file fixes the issue. Are there issues filed about this or shall I file one?

Best,

Ismael

[iulian dragos]

Not that I know of. It would be good to file a ticket, but please try
to be as specific as possible, ideally showing a reproducible case.

best,
iulian

> Best,
> Ismael

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

[Maxime Lévesque]

I'm also seing this behavior, let us know the ticket number, I'll follow it, and perhaps can help create a reproductible case.

ML

[ijuma]

On Tuesday, 4 October 2011 14:04:18 UTC+1, Maxime Lévesque wrote:

I'm also seing this behavior, let us know the ticket number, I'll follow it, and perhaps can help create a reproductible case.

I filed it without a reproducible case for now:

https://www.assembla.com/spaces/scala-ide/tickets/1000645-issues-with-recompilation-after-changing-branch-and-refreshing-projects

If you can create a reproducible case, that would be great. If not, I'll try to do the same.

Best,

Ismael