Summary: | NameLookup.findPackageFragment returns very incorrect package fragments | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Robert Konigsberg <konigsberg> | ||||||
Component: | Core | Assignee: | Jerome Lanneluc <jerome_lanneluc> | ||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||
Severity: | major | ||||||||
Priority: | P3 | CC: | caniszczyk, Olivier_Thomann | ||||||
Version: | 3.4.1 | ||||||||
Target Milestone: | 3.5 M7 | ||||||||
Hardware: | PC | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Attachments: |
|
Description
Robert Konigsberg
2009-03-02 19:21:17 EST
I have been able to create a test case that verifies this nasty, nasty behavior. I created a plug-in project and used the Hello, World Command template as a way to create a trigger. In the handler, I added this code: IProject project = ResourcesPlugin.getWorkspace().getRoot().getProject("asdf"); IJavaProject jp = JavaCore.create(project); IPath path = Path.fromOSString("/Users/kberg/Desktop/myf.txt"); IPackageFragment fragment = jp.findPackageFragment(path); System.out.println(fragment); I created a .jar file and stored it at "/Users/kberg/Desktop/my.jar". Again, notice that the size of /Users/kberg/Desktop/my.jar" is one less than path.toOSString(). Then I launched the Eclipse application. I created a java project called "asdf". I configured the project by adding the "my.jar" file to the build path as an external library. Then I triggered the command. Again, it returned my.jar. This was on my mac. I would try to fix this but I really don't know what you're going for here. Can you perhaps explain to me what this method should be doing? Or even, is there a good way for me to check after-the-fact that my IPath isn't actually part of the package fragment? I could see using IPath.isPrefixOf(IPath) but since I don't know what should really be happening, I'm afraid this will cause a different set of errors. Is there something I can do to expedite this? Jerome, have you looked at this yet? I'll try to have a look next week. In the meantime, 1. Can you please try with a more recent build? Does it still happen in 3.4.2? in 3.5M6? 2. Does it happen if the jar is internal to the project? 3. Can you attach /Users/kberg/Desktop/my.jar to this bug? (or a simplified version that reproduces the problem) 1. Can you please try with a more recent build? Does it still happen in 3.4.2? in 3.5M6? Reconfirmed with 3.4.2 on Linux. 2. Does it happen if the jar is internal to the project? I do not know what you mean. 3. Can you attach /Users/kberg/Desktop/my.jar to this bug? (or a simplified version that reproduces the problem) Really, the .jar has nothing in it. Just create a jar with any ol class in it, because the jar's contents are not relevant to this algorithm. But, I'll attach it. Yeah I already deleted the .jar, so I cannot attach it. Seriously, build a jar with one class in it. Or none. It still shouldn't return that .jar. Ping! Seriously, this is causing a real problem for us, and I am beginning to worry that this will not make it in to 3.5. I am happy to take a stab at this, as I've said, but I do not know what this method is supposed to do. Additionally, I will be happy with a workaround, but either way, I need some guidance, or at least a reply. And hey, I understand that you're busy and have plenty to do: if someone can point me in a direction that works around this then hey, I'll be more than happy to do that and reduce the severity. Let's start with getting all the information first. 1.I asked if the problem was reproducible in 3.4.2, you said yes and that's good. But I also asked if the problem was reproducable in 3.5M6, you didn't respond. 2. Then I asked if the problem happened if the jar is internal to the project? This is a jar located inside the project's folder (as opposed to a jar located in another project's folder, or an external jar which is located outside the workspace's folder). 3. I asked you to attach the jar. You replied that I can built it myself. This is not helping. A good start would be for you to provide the JUnit test that shows the problem. This test should be located in /org.eclipse.jdt.core.tests.model/src/org/eclipse/jdt/core/tests/model/NameLookupTests2.java To get the JDT/Core code, see http://wiki.eclipse.org/JDT_Core_Committer_FAQ#Where_is_the_JDT.2FCore_code.3F Hello Jerome, Thanks for your reply. It's good to see what is in the way. I'll try to address all of your comments here. It was unclear to me by your question that what you wanted was a verification on both versions. You gotta admit, "3.5M6?", as a sentence fragment, can be interpreted more than one way. In fact, I thought you were just looking for me to try either version. I will try to reproduce this with 3.5M6. Regarding whether the jar is internal or external, I am waiting on here -- I told you I did not know what you mean. Is comment #1 insufficient where I say" "I configured the project by adding the "my.jar" file to the build path as an external library." This doesn't mean I know the answer; I really do not have a good understanding of classpath internals. While I did, at first, say that you can just create any ol' jar to this project, that it didn't matter what the jar had, I admit that consequently I told you I would attach one, which I failed to do. Attaching in subsequent comment. I know that writing an actual test case would be good, but I'm really hoping that I can ask you to help out here: the truth is that it's become very difficult to try to figure out where source code is in the CVS repository. By that I mean that everything has been refactored in CVS, and the amount of time it takes for me to figure this stuff out is a huge pain in the butt. If you can help me out here by telling me the right way to get the latest and correct code from CVS, then I'll see what I can do. As you know, the amount of local knowledge to get started with Eclipse is not low. But more important than that, I have described reproducing the test case using manual actions because I don't have any idea how to create a test project that actually attaches the jar in that way. Or even how to create a dummy .jar file. I TOTALLY recognize that you're busy, but this is your domain of expertise, I know how to attach a jar using the UI, but not through the IDE, and if I do it incorrectly, I run the risk of not writing the test properly, and as such, perhaps it becomes marked as "working as intended", for instance. So really, your help is what I need here. When someone replies with enumeration like the one in 9, I suspect they're being defensive. I suspect it now, but I also hope I'm wrong. Clearly, you and I are going to need to work together to fix this, or at least, as a minimum, find a workaround. I can help out when there is communication, and I can't make progress without your shared experience. Created attachment 132400 [details]
minimal .jar file to be used in test case
Jerome, this still occurs with 3.5m6. Okay, before I head off to work, let me make sure I say: I've given all the information I can at this point, and am waiting to hear from you. I'm hoping this will be enough. I would also love to do a test case, but as I mentioned in the opening description, (and because of my limited knowledge of JDT and the framework) steps to reproduce have to be mostly prosaic and only partly code. But I assure you if you follow those steps (,and of course if my description of those steps were correct,) you should see the problem. So now I will wait to hear from you. I hope you have enough to go on. Let me know what you need! Thanks, Robert Created attachment 132460 [details]
Proposed fix and regression test
Fix and test released for 3.5M7 Verified for 3.5M7 using attached regression test |