On 11/9/06, Steve Loughran <[EMAIL PROTECTED]> 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
