| Summary: | Localization - ICU4J | ||
|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Anne Jacko <anne.jacko> |
| Component: | Releng | Assignee: | Nick Boldt <nboldt> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P1 | CC: | davidms, Ed.Merks, mtaal, stepper |
| Version: | unspecified | ||
| Target Milestone: | M5 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 252809 | ||
|
Description
Anne Jacko
I can't agree to this dependency for EMF core. CDO/Net4j are run-time technologies. All generic user interfaces are considered as usage examples. Therefor I always pulled the "technical reasons" card. Nevertheless I'll put it on my nice-to-have list. Does not apply to Teneo, being a runtime technology The following components use ICU4J (some plug-ins do not need it because of very limited manipulation of text in user input and output, which means that they would not use the corresponding core Java APIs anyway): Query Transaction Validation Ed, doesn't EMF already use ICU conditionally (i.e. if available) for string comparison via CommonPlugin.getComparator()? To me, that seems sufficient for saying we've satisfied this requirement. If people find other problems with text handling in the future, we could address them using the same approach. Does that sound reasonable? I suppose it's very reasonable take the position that because we provide access to ICU4J's collator, when ICU4J is available, we have satisfied the most important reason for the requirement. Indeed if there are other issues we've not considered, we can deal with them as they are reported in bugzilla. I'm going to say this is complete. Components that see this as applicable (Core, Query, Transaction, and Validation) use ICU4J (conditionally, in some cases). Teneo, Net4j and CDO consider themselves exempted as backend technologies. Closing all fixed releng bugs. |