.....
when in reality all you need to do is this
public void read(IFile file) {
BufferedReader reader = new BufferedReader(new InputStreamReader( file.getContents());
.....
}
which is part of the beauty of using IFile.
I think this second part is to get around the fact that the file may not "exist" in the test workspace when the test is run, so you have to drop to File because IFile.getContents() fails. This made it clear to me why I was experiencing a similar bug: we have been creating projects instead of importing the ones that are already in ICETests!
To properly import a project, just do this:
// Create the project description
IProjectDescription desc = ResourcesPlugin.getWorkspace()
.loadProjectDescription(projectPath);
// Get the project handle and create it
project = workspaceRoot.getProject(desc.getName());
project.create(desc, new NullProgressMonitor());
// Open the project if it is not already open
if (project.exists() && !project.isOpen()) {
project.open(new NullProgressMonitor());
}
I realize that most of the old workspace code is there because I wrote it begin with and it has been copied from test to test. I originally wrote it to test the Item's ability to *write* files to the project space, not read them, so it is easy to understand why I wrote it as such. What bothers me the most is that it took nearly three years for someone - that being me - to notice. So, I want to reiterate that if any of you have problems like this you need to let me know. Don't be timid and avoid asking your mean old boss why it breaks, especially if you are going to be passionate about things like extra wh ites pace or imPrOperLy SizeD WIdgEts.
I'll start cleaning them up this summer, but if you get to any of the cases where files should be read and they are being generated before me, please exchange what I originally wrote for the above and get rid of the generation code.
Jay
--
Jay Jay Billings
Oak Ridge National Laboratory
Twitter Handle: @jayjaybillings