| Re: [orbit-dev] Gack! I think Batik is my Nemesis |
Christian W. Damus schrieb: > In hindsight, I should have just created an org.apache.batik.ext bundle > for Batik 1.6, but we would still have the problem of incompatible API > changes in these dependencies between 1.6 and 1.7. We can't control the version policy of 3rd party libraries. We can only protect ourselves from surprises by being really careful about the version ranges when defining dependencies to them. Instead of (1.6.0,2.0.0] we should use (1.6.0,1.7.0]. > At least, though, we > wouldn't have org.w3c.* bundles that aren't W3C code. :-( That's unfortunate but IMHO it need to be fixed. We need to make sure that the Orbit bundles are of good quality. > - create bundles with "w3c" in the version to indicate true-to-W3C > code (e.g., org.w3c.css.sac_1.3.0.w3c_v200812102000). Happily, > 'w' sorts after 'v'. This resolves the problem of the org.w3c.* > bundles being adulterated with non-W3C content I like that approach the most. > In all cases, I think it might be necessary to export the packages in > the new Orbit bundles *without* version numbers. As I understand it, > this will avoid conflicts with clients that currently use Import-Package > with version ranges to get the current definitions of these packages. Do we know who is consuming it? Should we ask on the committers list to make them aware that they are consuming modified API? I don't like the idea of exporting packages without version numbers. > 2. Content from Java 1.4 I was lucky because I needn't to deal with this particular issue before (only theoretically). What is the recommended approach here? Export all packages from one bundle and let OSGi resolve the rest (with respect to the boot delegation property)? -Gunnar -- Gunnar Wagenknecht gunnar@xxxxxxxxxxxxxxx http://wagenknecht.org/
Attachment:
signature.asc
Description: OpenPGP digital signature