On Wednesday 30 May 2001 12:19, Toby Speight wrote: > 0> In article <[EMAIL PROTECTED]>, > 0> Egon Willighagen <URL:mailto:[EMAIL PROTECTED]> ("Egon") wrote: > > Egon> working on dh_java i encountered this: > Egon> > Egon> Duplicate library path: org/w3c/dom in both lib-dom-java and > Egon> lib-openxml-java,libxerces-java! > Egon> > Egon> In other words, the org.w3c.dom classes are given in three > Egon> packages... They probably have some version differences, but > Egon> it seem not correct that this redundancy is available... > Egon> > Egon> More practical, when doing dh_java, it is not possible to > Egon> determine which packages it relies on... > > Surely then the dependency will be on "( lib-dom-java | lib-openxml-java > | libxerces-java )", since having any of those will satisfy the runtime?
This will indeed be the outcome of dh_java... > Though if there are version differences, you could end up having to > introspect them all to find which ones will link with your package. :-( Indeed. This is a problem that needs to be solved in the future... > But I think the right way is to keep the interfaces package separate, > and have it depend on a virtual implementation package that's provided > by the actual implementations. > > If there are indeed different versions of the org.w3c.dom interfaces, > then versioned dependencies/conflicts are probably appropriate for the > implementation packages. Stefan argued that interface and implementation should not be seperated: "The classes for interfaces might be identical for all containers but at least the exception classes will differ - so it is very difficult to put the common classes in another JAR/package ans share them between all implementations." But it might indeed be "good" to place the interface classes in a seperate jar/package... this would enforce that the implementation *does* implement the actual interface, and not some look-a-like... I am not sure, but i guess, throwing exception *is* part of the actual interface... Egon