| Summary: | Localization - ICU4J | ||
|---|---|---|---|
| Product: | [Modeling] Acceleo | Reporter: | Anne Jacko <anne.jacko> |
| Component: | Core | Assignee: | Project Inbox <m2t.jet-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P1 | CC: | bjorn.freeman-benson, laurent.goubet, pelder.eclipse |
| Version: | unspecified | Flags: | pelder.eclipse:
pmc_approved+
|
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 252809 | ||
|
Description
Anne Jacko
ICU4J is a third-party library, since we aim at providing stand-alone capabilities to MTL, we try to reduce third-party jars usage to a bare minimum. Using ICU4J would force our users to have it in their classpath, not to mention the added 5 MB overall. would it be possible then to ignore this Galileo requirement? Laurent: Can you provide a bit more information about the impact to users would be? In particular: 1) for which plug-ins are you seeking the exemption? 2) which Java/ICU classes are used by these plug-ins? 3) What would the impact be of not using the ICU classes in those cases? (For example, if you use MessageFormat, then you might note that, in general, MessageFormat is reimplemented by ICU to support date, time and number format types. If none or your messages use the date, time or number format types, you could note that the usage has no impact. The Java classes replaced by ICU are listed in the Eclipse wiki page below. http://wiki.eclipse.org/ICU4J Also, have you considered the alternative of distributing the much smaller com.ibm.icu.base? It is available on the platform download page. Even with source, the download is only 170KB. The executable JAR is just 67KB. The wiki page above includes tips on how to avoid explicit dependencies on the ICU4J plug-in (but retain dependencies on the ICU packages). 1) All MTL plugins 2) For the most part, only MessageFormat would be 3) Motly none since MessageFormat is only used for our messages (see bug 253817) Ok now I told "mostly". The MTL evaluation engine makes rare uses to StringTokenizer and Character.isLetter() which would probably need to be altered also. Once again, the real reason we decided not to use it is because of the added dependency. As a user, I do not wish to download and set dependencies for the programs I use. As a developper, I do not want to force my users to do so. The downsides we're looking at (as far as the standalone capabilities are concerned) are : - Increased setup complexity for any thid-party (find and download ICU4J, set the classpath) - Forced packaging of ICU4J for any third-party app that would use MTL along with their product The added size is no concern as I didn't know about the "base" package you mentionned. I should mention that running MTL _only_ requires a minimal set of the MTL, EMF and OCl jars. Any additional third-party lib we are reluctant to set a dependency on. Adding project lead approval for an exemption Fixing this bug as exemption has been approved. All MTL Strings are externalized through pure java APIs. This was part of the Ganymede release status tracking. Closing. |