Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-patch] Patch for org.eclipse.cdt.ui.tests 

Alain Magloire wrote:


This is a multi-part message in MIME format.
--------------070209050101010100000103
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Attached is a patch I am about to commit into org.eclipse.cdt.ui.tests. There are no new tests there, but I have changed all the QNX specific pr numbers to the equivalent bugzilla pr number. The patch also includes some general cleanups (removed unused imports/variables etc.) 



Few comments:
- There is a need to rewrite the parser that is constructing the model
 but that should not affect you(testing) at all, since the API should not change.

- I see that you are using org.eclipse.cdt.internal.model.*, in theory
 this is the implementation and they are not visible.   The only thing
 visible is the interfaces.  For example, if I want to see all the
 objects in an archive:

 import org.eclipse.cdt.model.*

 IFile file = ResourcePlugin.getResourcePlugin().getFileForLocation("project/library/libfoo.a");
 ICElement celement = CoreModel.create(file);
 if (celement instanceof IArchive) {
    IBinary[] bins = ((IArchive)celement).getBinaries();
    for (int i = 0; i < bins.length; i++) {
	// What we expect:
       System.out.println("Archive contains object " + bins[i].getElementName());
    }
 }

...

The only entry points are in CoreModel.  One can not create an Archive, like this
  IArchive ar = new Archive("foobar.a");
There were a couple reasons I went to the internal packages. First off, when I started writing the tests I didn't know all the rules, and noticed there were some checking in the JDT stuff for creating new files that did not happen in the CDT side of things, so there are a couple tests what manually try to create various objects (Archive, TranslationUnit etc.) with invalid types of files. I can remove this to partially remove that usage, and cleanup the references in the tests to use the interfaces instead of the internal classes. Another place I am using the internal packages is the CProjectHelper class to try to find Archives, Binaries etc. I needed to use the internal classes to be able to make sure the parsing of the project was finishes before I started looking for a specific children (the getChildren(boolean) call on the various container classes). Is there any way, through the external interfaces, to check that all the children have been parsed and are available? 

Thanks,
-Peter

Back to the top