Re: dependencies on XML Apis (&c)

[Xavier Hanin <xa...@gmail.com>]

On 11/9/06, Steve Loughran <st...@apache.org> wrote:
>
>
> Now, I have one more metadata issue, its one that exists in maven-land
> too; both need to address it. Maybe, just maybe, OSGi addresses it.
>
> How do you stop competing XML parsers, XSL engines or stuff implemented
> in javaee.jar from getting duplicated in a classpath?


Yes, distinguishing an implementation form a specification is something
important for a good dependency manager, but it's not easy to solve. I
thought about a solution before Ivy 1.0, but had to defer it because it
wasn't satisfying. It's also something under discussion in JSR277 and there
is no easy solution for the moment. But this would be a good thing to
address in a 2.0 version.

Here is a bit of the httpunit dependencies, as inferred from m2:
>
>   jtidy by jtidy        4aug2000r7-dev  integration
> maven2  false           135 kB
> js by rhino     1.5R4.1 integration     maven2  false           583 kB
> nekohtml by nekohtml    0.9.1   integration     maven2  false           66
> kB
> --- xerces by xerces    2.4.0   integration     maven2  false
> 875 kB
> xercesImpl by xerces    2.6.2   integration     maven2  false
> 987 kB
> xmlParserAPIs by xerces 2.2.1   integration     maven2  false           81
> kB


Here the problem is even more difficult because there should be a conflict
between the 2.4.0 and 2.6.2 version of xerces, but the dependency managerr
can't know that xerces and xercesImpl are similar.

Two copies of Xerces, and a version of xmlParserAPIs that may or may not
> match.
>
> Ideally you'd want to know which JARs declared interfaces (each by a
> unique name, or even a unique URL), and which JARs implemented them.
> Then at least you could warn if there was a conflict. Deciding which
> version is newer is trickier; the metadata would have to include version
> information about the interfaces of an artifact:
>
> <implements uri="http://jcp.org/233/dom" version="3.0" />
>
> so not only would a conflict between xerces and crimson show up, the
> resolver would know not to use crimson.


This seems to be a good idea. But you also would need to identify a jar
which only declares the api without implementing it (a jdbc.jar in a
modularized jre for instance). In this case to compile you need only the
API, to run you need any implementation. And sometime you may know that an
implementation is buggy and want to indicate the incompatibility. This is a
difficult problem.

Xavier

-steve
>
>
>