Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 343777

Summary: Eclipse stop responding with an recursive "import"
Product: [Modeling] Epsilon Reporter: Rui Carlos Gonçalves <ruicag>
Component: CoreAssignee: Antonio Garcia-Dominguez <agarcdomi>
Status: CLOSED FIXED QA Contact:
Severity: major    
Priority: P3 CC: agarcdomi, dkolovos
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard: interim

Description Rui Carlos Gonçalves CLA 2011-04-25 18:00:08 EDT
If we create an EOL file and import the file itself, Eclipse will stop responding. It will stop responding again after reopen it. The only way I found to solve the problem was using a external editor to remove the recursive import.
The same seems to happen when we import file A on file B, and import file B on file A.
Comment 1 Antonio Garcia-Dominguez CLA 2012-08-02 06:44:02 EDT
(In reply to comment #0)
> If we create an EOL file and import the file itself, Eclipse will stop
> responding. It will stop responding again after reopen it. The only way I
> found to solve the problem was using a external editor to remove the
> recursive import.
> The same seems to happen when we import file A on file B, and import file B
> on file A.

This bug hit another user, as mentioned in this thread:

http://www.eclipse.org/forums/index.php?t=rview&goto=899646

I've committed a fix in SVN r1919.

I've added getParent/setParent methods to the IEolLibraryModule interface, which is the one that handles the imports, and a getSourceURI to the IModule interface. EolImport will try to look first for the script that is to be imported among its ancestors: if it finds it, it will reuse it instead of loading it again. That should work with any kind of circular or recursive import.

I've also added tests for:

1. Script tries to import itself.
2. Script A imports B and B imports A.
3. Script A imports B, B imports C and C imports A.
Comment 2 Dimitris Kolovos CLA 2012-11-08 16:42:38 EST
Fixed in 1.0