| Summary: | Cannot create Java EE artifacts: servlet, beans, etc. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP Java EE Tools | Reporter: | Kaloyan Raev <kaloyan> | ||||
| Component: | jst.j2ee | Assignee: | Kaloyan Raev <kaloyan> | ||||
| Status: | CLOSED FIXED | QA Contact: | Chuck Bridgham <cbridgha> | ||||
| Severity: | blocker | ||||||
| Priority: | P1 | CC: | david_williams, thebravoman | ||||
| Version: | 3.0 | ||||||
| Target Milestone: | 3.0 M6 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Kaloyan Raev
This problem should also explain some of the failing JEE JUnit tests. The root cause appears to be in WTPJETEmmitter.getJarredPluginPath():484. There the location of the JAR is retrieved by calling "bundle.getLocation()". This method returns the location of the plugin JAR, but prefixed with "resource:file:". It seems that on line 484 there is an attempt to remove this prefix from the string - substring(7). I suppose that the prefix was shorter in previous releases of Eclipse SDK and it has been changed in the last days. The getJarredPluginPath() method is not called if the respective plugins are checked out in the workspace. This is why this problem did not appear in my dev environment. Created attachment 94183 [details]
patch
Patch that replaces
bundle.getLocation().substring(7);
with
FileLocator.getBundleFile(bundle).getPath();
Mid-air collision ... and looks like you've already gotten it ... but, for reference, there's what I was writing. Think this is related to bug 224384? Issues with getJarredPluginPath have been found in P2'd Platform, where we install our code in "eclipse/dropins" instead of in the old eclipse/plugins and features. The incorrect path look very similar to the original bug 224148. (which also provides a solution ... see https://bugs.eclipse.org/bugs/show_bug.cgi?id=224148#c9 And, just FYI, if required, we could declare with this bug, and say "we don't work with a P2 type install" with this I-build ... but, I certainly agree it should be fixed for M6, if not this I-build. David, thank you for the additional references. I have just dropped to fix and released it to the build. This bug blocks smoke testing and I would not wish to declare this I-build in this case. I suggest we wait for the build and I will re-smoke. BTW, there is a build already running. Could we cancel it and trigger a new one? This will speed up the whole thing with an hour or two. *** Bug 224384 has been marked as a duplicate of this bug. *** Verified with wtp-sdk-I-I20080331115711-20080331115711 Closing |