Bugzilla – Full Text Bug Listing
| Summary: | backward compatibility and dependency on com.ibm.icu | ||
|---|---|---|---|
| Product: | [Tools] GEF | Reporter: | Eugene Kuleshov <ekuleshov> |
| Component: | GEF-Legacy Draw2d | Assignee: | Anthony Hunter <ahunter.eclipse> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | ahunter.eclipse, libinv, weisz |
| Version: | unspecified | ||
| Target Milestone: | 3.5.0 (Galileo) M5 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Eugene Kuleshov
Is there a work around? Can I manually change this dependency using PDE? ( Any pointers ) This issue is discussed in Bug 214900 and Bug 134789 . GEF does not directly reference a specific version of icu4j and we expect that GEF is using the same icu4j that is shipped with the Eclipse platform. Note as well that GEF 3.4.1 is not supported on version 3.3 of the Eclipse platform. GEF 3.4.1 is not supported on version 3.3 of the Eclipse platform since it requires com.ibm.icu version 3.8.1 included in the Eclipse 3.4 release. I don't understand last comment about GEF. The issue reported is about dependency from draw2d and zest to a recent version of icu4j without specifying version of that dependency. Please specify version of required icu4j explicitly. What version(s) of icu4j do you have in your configuration? Are you using Eclipse 3.4? (In reply to comment #5) > What version(s) of icu4j do you have in your configuration? > Are you using Eclipse 3.4? Anthony, I am not, but users of our tools have no choice but to use draw2d from Eclipse 3.4 update sites even for Eclipse 3.3. From what I see all it would take to fix the issue is to add proper version declaration on packages or bundles required by draw2d plugin. So, resolver would pickup the right versions. (In reply to comment #6) > > Anthony, I am not, but users of our tools have no choice but to use draw2d from > Eclipse 3.4 update sites even for Eclipse 3.3. From what I see all it would > take to fix the issue is to add proper version declaration on packages or > bundles required by draw2d plugin. So, resolver would pickup the right > versions. > If you have Eclipse 3.3, you cannot get Draw2D 3.3 from any update sites? This is the bug then right? (In reply to comment #7) > If you have Eclipse 3.3, you cannot get Draw2D 3.3 from any update sites? This > is the bug then right? Sorry, I don't understand the question. Judging from the draw2d plugin version it supposed to be backward compatible with the previous versions, so as icu4j plugin is backward compatible from the API point of view. However draw2d does not declare dependencies properly and making some implicit assumptions on what version of icu4j will be available at runtime, so its requirements can be matched incorrectly because of that (hence the stack trace above). Is it a problem to specify required version of dependencies? (In reply to comment #8) > (In reply to comment #7) > > If you have Eclipse 3.3, you cannot get Draw2D 3.3 from any update sites? This > > is the bug then right? > > Sorry, I don't understand the question. Judging from the draw2d plugin version > it supposed to be backward compatible with the previous versions, so as icu4j > plugin is backward compatible from the API point of view. However draw2d does > not declare dependencies properly and making some implicit assumptions on what > version of icu4j will be available at runtime, so its requirements can be > matched incorrectly because of that (hence the stack trace above). Is it a > problem to specify required version of dependencies? > Yes, Bug 134789 says that we cannot Require-Bundle, we must Import-Package . And import package does not have a version dependency. I will investigate further with the platform team. Not sure I understand the consequence: the outcome of this limitation is that it will fail at runtime, instead of failing at load time ? At load time it would "fail" gracefully with an expected message, while at runtime it will fail kind of hard to figure out without some additional digging ? (In reply to comment #10) > Not sure I understand the consequence: the outcome of this limitation is that > it will fail at runtime, instead of failing at load time ? At load time it > would "fail" gracefully with an expected message, while at runtime it will > fail kind of hard to figure out without some additional digging ? Not only that, but it also doesn't tell p2 resolver what is the right compatible version should be used. Found a solution We need to specify Import-Package: com.ibm.icu.text;version="[3.8.1,5.0.0)" To indicate that we need version 3.8.1 of the ICU4J bundle or higher. Committed to HEAD |