Hi Sergey
In the absence of any comment from you, I will have to proceed as I
think best and just relax the bounds.
Regards
Ed Willink
On 26/11/2012 18:31, Ed Willink wrote:
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
_______________________________________________
mmt-dev mailing list
mmt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/mmt-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
|
