Re: [Taverna-hackers] Translating T1->T2 workflows

[Stian Soiland-R. <soi...@cs...>]

On Fri, Nov 28, 2008 at 15:52, Tom Oinn <mer...@ca...> wrote:

> I don't think the expected behaviour is defined anywhere, it's not
> something I was ever able to determine from the maven docs. I think this
> is one of the reasons for the exclusion block on the dependency element
> in the pom, so you can make it explicit which version you want to find.

No, but I think what Maven does is some kind of version negotiations,
so at least for two artifacts of the same groupId and artifactId you
will only get one of them. I don't know what order they are put on the
classpath when running junit tests, but it should be easy to find out.

In this case within Raven the problem can occur because of a
depth-first search instead of a width-first search, and because we
don't detect multiple artifacts of different versions within the same
dependency tree.


As for artifacts which classes with the same name under different
groupIDs and artifactIDs - now that's a bit worse to detect a priori..
  - ref axix:axis-wss4j vs org.apache.axis:axis-wss4j vs wss4j. (all
with different dependency statements!)

(Which is why I now deploy our
not-compatibly-deployed-in-official-maven-dependencies under the
official groupID and artifactID, but with a -taverna version)


> In general through this is a nasty problem, we can force a particular
> dependency to be used for a given artifact but if classes are ever
> returned from outside of that context you'll get the cast issues again
> anyway. Best thing I think we can do is throw up a warning when
> assembling a class loader which has more than one version of the same
> artifact in its dependency list.

Yes, and to then log from where they came. At least then the developer
can then just override this in the plugin definition and remove the
nasty one.

(If there actually were two JARs needed with the same classnames, but
in different versions, the only safe way would be to split into two
plugins that don't talk directly with each-other - and that definitely
don't use any classes depending on the conflicting ones in their
interface definitions! )


-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester