On Thu, Oct 14, 2010 at 10:17, Andreas Truszkowski <[email protected]> wrote: > Ok it seems that two libs can't see each other. But also here it works > without problems in the developers workbench. How can it be?
In Taverna's plugin system, class loaders are built according to the specified Maven dependencies. When running the developer version from within Eclipse, everything is munged into a single classpath, making most stuff work - but also giving you potential issues like you had with multiple copies of vecmath. However, when running Taverna standalone, the plugin system will make isolated classloaders according to the Maven dependencies. A Maven module can only see his own code, everything directly stated as a dependency, and all the dependencies of those dependencies again, recursively. (Searched depth first). So every module (Maven dependency) will get its own classloader which can only see things 'below' him. It might be depended upon in three different modules - but will not be able to see either of those or their other dependencies. This allows say JDom to be shared across plugins, even if the different plugins might have conflicting dependencies on say Axis. This means that if B is trying to use A without having it as a direct or indirect Maven dependency, it will not be able to find this. (If B is built using Maven this would be a bit strange - as it should not compile without the dependency to A) In your case it sounds like it is the interface class that can't be found - so make sure the POM for IAtom is included in the POMs for each of the modules providing IAtom implementations - in Eclipse you can use the 'View hierarchy' function to find these. If you need to edit these POMs, you should try to push your changes upstream so that they end up in the Maven repository you're using. In some cases this is not practical - and you might be forced to 'fork' the POM - in which case you should as a minimum use a different version number - like <version>2.3.2-taverna-1</version> - you would then need to provide your forked version from your plugin's Maven repository. (For the future we're moving to OSGi for the plugin system, this should separate out this dependency specification from the POM, allowing you to override such things for your plugin.) Also make sure they all refer to the same version of the interface containing POM - otherwise you might something confusing like "IAtom cannot be cast to IAtom". When building with Maven you will not normally be able to specify a loop A->B->A (or A->B->C->A) - if this is your case, most probably due to some use of Class.forName() - then first see if you can work it out by splitting A into A and A' with A->A' and A->B->C->A'. - alternatively we do have some workaround code for loops - but I'm not sure if Java's classloaders would cope well with that. (In many cases, calls to loadClass() (loading a class by name) should use the thread context loader - which you can set from your activity - should take in a parameter to the classloader to use, or ) -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ taverna-hackers mailing list [email protected] Web site: http://www.taverna.org.uk Mailing lists: http://www.taverna.org.uk/about/contact-us/ Developers Guide: http://www.taverna.org.uk/developers/
