> No, the JVM does not know anything about versions or interface > compatibility. All it knows is that a certain class a.b.c.MyClass from > the classloader urlclassloa...@1239812389 is different from a class > a.b.c.MyClass from the classloader urlclassloa...@532143. This goes > for interfaces as well - so if your class is implementing > a.b.c.MyInterface from @1239812389 but not a.b.c.MyInterface from > @532143 - then it cannot be assigned to a @532143-MyInterface field - > used as such a parameter and so on. > > In our case the different classloaders correspond to different POM > files - and there's one per Maven groupId/artifactId/version > combination - it does not matter which of these is different - if one > or more of them is different it will be a different classloaders. > (However these classloaders are linked through the stated Maven > dependencies - meaning that a classloader would also be able to see > classes from those classloaders - and it will first search these > before it will look in it's own JAR file. > > I am sorry that I still did not catch you exactly (forgive my stupidness :-) ) Say 1. I compiled my plug-in which depends on a.b.c.Interface 0.7-SNAPSHOT. When workbench load it, the classloader of the plug-in (say urlclassloa...@1239812389) will load the 0.7-SNAPSHOT jar. The classloader of the workbench (say urlclassloa...@532143) has loaded 0.6 jar and therefore it knows that my plug-in does not implement the right interface in 0.6 jar. 2. I compiled my plug-in which depends on a.b.c.Interface 0.6. When workbench load this plug-in, since 0.6 jar is already loaded by the classloader of the workbench (urlclassloa...@532143) so that the plug-in classloader (say urlclassloa...@1239812389 ) will see and use it. This means that the plug-in classloader will NOT load the 0.6 jar again (correct?) but use the 0.6 jar which is already loaded (by another classloader). In this case the workbench knows that the plug-in implements the right interface (a.b.c.Interface in urlclassloa...@532143).
My understanding is from your words saying that " that a classloader would also be able to see classes from those classloaders". Suppose there is a pom tree like this p1-->p2 (i.e., p1 depends on p2). If both p1 and p2 depends on p3, and the classloader of p1 already loaded the artifact defined by p3, then p2 will NOT load p3 again but just use the one that is loaded by p1? In my case, p1 is the workbench (or some artifacts in the workbench that depends on the 0.6 jar), p2 is my plug-in, and p3 is the 0.6 jar. Is that correct? :-) > No, we should really maintain a wiki page of what those versions are > for different releases. > > You can look at the POM used for the release of the workbench itself - > ie. > http://taverna.googlecode.com/svn/taverna/products/net.sf.taverna.t2.taverna-workbench/tags/taverna-workbench-2.1-beta-2/pom.xml > - or due to the mentioned sorting - at > http://taverna.googlecode.com/svn/taverna/ui/net.sf.taverna.t2.ui-exts/tags/ui-exts-0.9/pom.xml > > I wonder if there should be a top pom for each Taverna release and it defines all the properties that every plug-in should use. Thanks!! Wei -- Wei Tan, Ph.D. Computation Institute the University of Chicago|Argonne National Laboratory http://www.mcs.anl.gov/~wtan ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ taverna-hackers mailing list [email protected] Web site: http://www.taverna.org.uk Mailing lists: http://www.taverna.org.uk/taverna-mailing-lists/ Developers Guide: http://www.mygrid.org.uk/tools/developer-information
