dependencies on XML Apis (&c)

[Steve Loughran <st...@apache.org>]

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?

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

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.

-steve

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