Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-VerveineJ Milestone-4.7
New issue 895 by andreho...@gmail.com: Lack of entities in verveineJ model http://code.google.com/p/moose-technology/issues/detail?id=895
I'm parsing the single .java attached file (I have also copied in the end of this message), and I have some points:
- A stub class FileUtils is not created. As consequence the receiver os the static invocation "FileUtils.close(ti)" (see last line) is "nil". - A stub class ArchiveScanner (superclass) is not created.
What do you think about that?
In addition (I believe it is OK):
- A stub class Map is created as FAMIXParameterizableClass (it should just be used to Generics, no?). - A 'V' FAMIXParameterType is created - A Comparable is created as FAMIXParameterizedType
Maybe these three points are coming from the class Map in Java, then it is OK.
Basically this is the code attached: ========= public class TarScanner extends ArchiveScanner { ... protected void fillMapsFromArchive(Resource src, String encoding, Map fileEntries, Map matchFileEntries, Map dirEntries, Map matchDirEntries) { TarEntry entry = null; TarInputStream ti = null;
try { try { ti = new TarInputStream(src.getInputStream()); } catch (IOException ex) { throw new BuildException("problem opening " + srcFile, ex); } while ((entry = ti.getNextEntry()) != null) { Resource r = new TarResource(src, entry); String name = entry.getName(); if (entry.isDirectory()) { name = trimSeparator(name); dirEntries.put(name, r); if (match(name)) { matchDirEntries.put(name, r); } } else { fileEntries.put(name, r); if (match(name)) { matchFileEntries.put(name, r); } } } } catch (IOException ex) { throw new BuildException("problem reading " + srcFile, ex); } finally { FileUtils.close(ti); } } ... =========
Comment #1 on issue 895 by andreho...@gmail.com: Lack of entities in verveineJ model http://code.google.com/p/moose-technology/issues/detail?id=895
.java file.
Attachments: 517988-TarScanner.java 3.3 KB
Updates: Labels: -Milestone-4.7
Comment #2 on issue 895 by tu...@tudorgirba.com: Lack of entities in verveineJ model http://code.google.com/p/moose-technology/issues/detail?id=895
Have you tried with the required libraries?
Comment #3 on issue 895 by andreho...@gmail.com: Lack of entities in verveineJ model http://code.google.com/p/moose-technology/issues/detail?id=895
No, but this is the point: note that I'm talking about the creation of stub entities.
For example: the invocation "FileUtils.close(ti)" should generate (1) a stub class FileUtils and (2) an invocation with FileUtils as receiver.
-> The invocation is created ok (but with nil receiver) -> The stub class is not created
Comment #4 on issue 895 by tu...@tudorgirba.com: Lack of entities in verveineJ model http://code.google.com/p/moose-technology/issues/detail?id=895
This is a known issue.
Essentially, if the external libraries are not in the classpath, you will not get proper information.
It would be great to have this improved.
Nicolas, any chance for that?
Comment #5 on issue 895 by andreho...@gmail.com: Lack of entities in verveineJ model http://code.google.com/p/moose-technology/issues/detail?id=895
BTW this problem also occur with JDT: without required libraries such kind of "simple" bindings are lost.
Comment #6 on issue 895 by tu...@tudorgirba.com: Lack of entities in verveineJ model http://code.google.com/p/moose-technology/issues/detail?id=895
This will appear everywhere :). But, could you try with the required libraries, too?
Comment #7 on issue 895 by andreho...@gmail.com: Lack of entities in verveineJ model http://code.google.com/p/moose-technology/issues/detail?id=895
I mean, I have tested using only the JDT parser (without VerveineJ) and I saw that this is a problem with JDT. As VerveineJ is based on JDT, this problem reflects in VerveineJ too...
Yes, I have tried with required classes and it works OK as expected.
Updates: Status: WontFix
Comment #8 on issue 895 by tu...@tudorgirba.com: Lack of entities in verveineJ model http://code.google.com/p/moose-technology/issues/detail?id=895
(No comment was entered for this change.)