| [mmt-dev] [QVTo] com.ibm.icu.text package bounds |
|
Hi Sergey QVTo has two [4.0.0,5.0.0) import package ranges for com.ibm.icu.text. It looks like these will break in M4. Do you know of any restrictions on them? Should we just remove the upper bound as recommended? Regards Ed -------- Original Message --------
I wanted to be sure everyone was aware of 3 changes coming to ICU4J, shipped with Eclipse SDK, that will be in Kepler M4 (more specifically, our I-build on 11/27). [1] 1. The largest change is the major version number. The ICU project has changed the system by which they do versioning, so this cycle the major version jumps from 4 to 50. The code itself is (still) just a minor increment, but for their own (non-Eclipse, non-OSGi) reasons decided to change the way they do versioning. In the past we have always recommended people leave the prereq range for this bundle or imported packages open ended (no upper bound) ... just for reasons like this ... but if anyone did not heed that advice, you will need to react now, before M4. Not only would it still be appropriate to not specify an upper bound, it is far better to leave your lower bound as low as you can (as low as it currently is) ... you only need to increment lower bounds, if your code uses something that is only in the higher version of a bundle (e.g. a new API -- if you only need a fix in a higher version, not new API, a good technique is to have your bundle specify the version of API you need (low) but have your feature "require" the bundle at the fixed version). A good technique for bundles to consume ICU4J is to use "import package", (because there are actually two bundles the packages might come from). Hence, your manifest might contain something like: Import-Package: com.ibm.icu.text;version="3.6.1", com.ibm.icu.util;version="3.6.1" But there are some projects that prefer to (or, have to) require the actual bundle Require-Bundle: com.ibm.icu;bundle-version="3.4.4" Note that 4.2.2 was in both Juno and its predecessor Indigo; Helios used 4.2.1. Leaving your lower bound as low as you can, means you will be most compatible for everyone that "mixes and matches" bundles to create their own products; they (and you) can avoid split streams if you have no concrete need to increment lower bound. 2. A change that sounds large, but is believed not, is that there is technically some API changes in 50.1. These are not due to a change in ICU4J, per se, but instead in how we in Orbit take the "standard version" of ICU4J and provide it for Eclipse. Long ago, there were a few tweaks to the standard ICU4J made specifically for the Eclipse version, so it would be compatible with "CDC Foundation" libraries. But, that has not been required for a release or two, and it is dangerous to have two versions of third-party code "in the wild" that are not perfectly compatible. If you are recompiling, you there is only one method that's not compatible, involving "BigDecimal" which we suspect is not in wide spread use, if at all. If you are interested in binary compatibility, there are 4 other methods that changed with respect to method arguments, changing "String" to "CharSequence". If anyone finds issues with these 5 cases, please let us know in the Orbit bug [2] so we better understand the impact of this standardization. Attached to the Orbit bug [2] is a table that details the changes [3]. It provides full signatures, if you wanted to search your code for the methods involved. 3. There is a special, reduced "implementation" of the full ICU bundle ("com.ibm.icu") which is named "com.ibm.icu.base" that does not actually implement most of its function, but provides places holders for the APIs (i.e. packages are the same name so "import package" is still satisfied). This is for people/projects who a) mostly only care about supporting English or very simple NL support, and b) are concerned about having a small footprint, such as for an RCP App, and c) still need a "place holder" for the dependency packages due to other bundles they require. (This use assumes use of "import package") The change that is coming, is that this special packaging will no longer be provided on the Eclipse Platform download page nor in the Eclipse repository, but will still be available from Orbit where it has always been available [4]. We in the platform are trying to reduce/streamline our builds and packaging and us providing this bundle is redundant with the Orbit bundle. The current plan is to remove this in both Kepler and in Juno SR2, but of course the same 4.4.2 version will still be there in the Juno (composite) repository, just not on DL page. For Kepler, the 50.1 bundle will only be available from Orbit. Again, let us know if this has impacts we have not anticipated. This should impact hardly anyone in the release train, but I did notice that "rap examples" appears to use it, so depending on RAP does their build, they might have to switch to Orbit repo, if you were not already using that. Thanks for reading this long note and reacting to any changes required. We will all be better off over the years ahead. Please say if there are questions or concerns. [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=386766 [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=386657 [3] https://bugs.eclipse.org/bugs/attachment.cgi?id=223578 [4] https://bugs.eclipse.org/bugs/show_bug.cgi?id=395003 |
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2793 / Virus Database: 2629/5918 - Release Date: 11/25/12