target directories _should_ be marked derived
Closed this issue · 5 comments
It is frustrating that sbt-eclipse doesn't manage the output directories appropriately making searches for resources in the workspace matching .class files and other crap in the target directory.
I can fix this manually by going to every single 'target' directory, right clicking, going to Properties, and checking 'derived' but sbt-eclipse should do this for me, otherwise every time I have to re-generate the projects I have to manually do this step again.
AFAIK that's a workspace setting, not a project setting, so the metadata is probably not where the .classpath/.project files are.
If I manually check derived on the folder, the problem is solved until the next time I run 'sbt eclipse' and the project files are overwritten, removing the change.
If it is not associated with the project, how is the sbt plugin reverting the change?
I will try and reproduce it again, and look for the difference in eclipse config files
It does not happen merely by re-running the sbt eclipse plugin, but does when the project is removed and re-added, which I have been doing more frequently recently due to other issues.
A few other things seem to trigger it, but I can not see any difference in the .classpath, .settings, or .project files.
It would be great if sbt-eclipse could do something about the problem, flagging that directory to not be found by search, but if it is a workspace setting that is sad. It appears to be something that the eclipse search component manages on its own.
m2e (and the scala add-on for that) doesn't have this problem because it configures maven and eclipse to share the same output dir. I'm not sure there are any solutions other than that, which comes with some drawbacks -- though it wouldn't be awful if both sbt and eclipse shared a zinc instance.
If it is not associated with the project, how is the sbt plugin reverting the change?
It's sbt clean, deleting the directory removes it from Eclipse, including it's associated "derived" flag. I'm equally annoyed by this behaviour but I couldn't find any suitable workaround (except not doing Sbt clean and building only from Eclipse).
I bet the data is stored somewhere in <workspace>/.metadata/.settings, hopefully in a text file, not binary. Sbt-eclipse could then take an additional parameter, the workspace location, and generate this. But that will only last until the next sbt clean.