Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orbit-dev] Gack! I think Batik is my Nemesis

Hi, Gunnar,

Thanks for your response and apologies for the very late reply. It's a busy time, as I you can probably imagine!

I have some replies in-line, below.

cW

On 11-Dec-08, at 2:25 AM, Gunnar Wagenknecht wrote:

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].

Yes. That's the strategy that the Batik bundles, themselves, use. I think it would be a good idea for the Orbit project to recommend this, in general, for Eclipse dependencies on 3rd-party code. I don't know that we have published any explicit statement in that regard.


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.

Absolutely!


 - 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.

Thanks for seconding that. It's my favourite, too. I think it also aligns with some of the proposals we have seen for other libraries that come from multiple sources (e.g., javax.mail Geronimo implementation versus whatever the other was).


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?

That's a good idea. I shall send a note out to eclipse-committers when I return to this task. I'm currently waiting on more CQs from the GMF team for missed dependencies in the Batik 1.7 contribution, but resolution of the W3C problem could proceed in parallel, I think. I would just have to see whether Batik 1.6 is compatible with the original W3C APIs (the delta is very minor).


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)?

I don't know. I was hoping that David might comment ... he has considerable experience in this from his work with the Apache XML components. As far as I recall, the solution involves requiring the system bundle, but that's quite a long time ago now ...



-Gunnar

--
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx
http://wagenknecht.org/

_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev

--
Christian W. Damus
Senior Software Developer, Zeligsoft Inc.
Component Lead, Eclipse MDT OCL and EMF-QTV
E-mail: cdamus@xxxxxxxxxxxxx





Back to the top