RemovalOfJavaIOFileInTigerstripeCore

____Work in Progress____

Problem

In its early days Tigerstripe's core was completely "Eclipse Free" so it could be run from a JVM without needing to start Eclipse Headless. Because of that, there is a number of occurrences of java.io.File to access the disk, which means that any change on a file (save an artifact thru the Art. mgr e.g.) is not seen directly by Eclipse, and we're forced to call "Refresh" periodically, it is impossible to use the Job API properly to have "Workspace Modifying Jobs", etc... leading to inefficiency at best, and sometime deadlocks.

Java.io.File uses should be replaced with IResource/IFile where applicable, which should allow to use the Job API properly and get rid of some of the "refreshes".

Uses of java.io.File

An initial search for java.io.File in the base.core plugin of tigerstripe revealed that:

• java.io.File.pathSeparator is used in a number of spots. This should be replaced by IPath.SEPARATOR. However, this means all paths will have the "UNIX '/'". This needs to be tested.
• All files that were created in the workspace were using absolute paths, that now need to be made relative to the workspace. This should simplify their creation and have minimum impact.
• All files that were created outside of the workspace (Tigerstripe install dir, e.g.) may be a problem. [NEED MORE INVESTIGATION]

Thoughts

• it seems we should use this exercise to migrate the ArtMgr to an API closer to what we would have once we've migrated to EMF.
  • In particular the doSave(...) methods on IAbstractArtifact should disappear and be replaced by an explicit repo.store(...) type of call.