On Tue, Sep 15, 2009 at 19:55, Wei Tan <[email protected]> wrote: > I did not make any change to the source code when I switched the > dependency between 0.7-SNAPSHOT and 0.6. > In this way JVM still knows that my code was compiled against which > version, right? -- It knows that my code > implements interface defined in 0.7-SNAPSHOT and not 0.6 (although the > code itself does not change)
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. This also opens for many 'interesting' situations where you could end up with two dependencies that each depend on two different versions of Axis for instance.. this means that which Axis *implementation* and from which *classloader* you get depends on which is searched first - an order which is determined by a HashSet. This is part of the motivation for why we went with flat classloaders (one per plugin) in the plugin system of the platform where at least you would get consistency in such misconfigurations. > You introduced <property/> in Maven to keep version number synchronized > across poms, right? Yes, or at least to have fewer places to change them - in our code now such properties would be defined in the top level pom for each of those modules I mentioned earlier. > As a plug-in developer, I guess the "best practice" is, to test against > a stable version (like T2.1 beta 2), > and use the stable artifacts that this stable version uses? Otherwise, That's right - unless there's a feature from the next version you need - or you want to test your plugin against an upcoming Taverna release. (You would still need to rebuild your plugin once our stable versions for that release have been deployed - typically a few days before the actual release) > if I use SNAPSHOT artifacts, I should > use them all, i.e, to build the whole workbench using the latest > SNAPSHOT, and test against it. Exactly - you'll have to go all or nothing.. This does not mean that you can't keep *your* plugin or third-party dependencies as SNAPSHOTs while developing - just that your Taverna dependencies should be consistent and match the Taverna distribution you are targeting. > That would make the dependency network less interrelating and again, I > found the variables defined as > <properties/> in pom files quite useful to identify the stable version > of artifacts. However, currently those > definitions are spread in multiple pom files and not easy to find. 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 -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester ------------------------------------------------------------------------------ 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
