On Tue, Sep 15, 2009 at 03:38, Wei Tan <[email protected]> wrote: > Problem solved -- the updated 0.9-SNAPSHOT jars (on which my plug-in > relied on) do not work with T2.1 beta 2 workbench. I am using the stable > jars that T 2.1 beta 2 relies on instead. > Now I get a better understanding of what is SNAPSHOT :-)
I assume what happened was that you depended on snapshot versions of Workbench UI libraries, but the problem is that when loading this in the 2.1 beta 2 workbench, you ended up with duplicate libraries, as Raven (our current plugin system) will blindly trust your version numbers. Below follows lots of technical stuff that I don't think many of us really fully understand, me included. So take it with a pinch of salt..! As in Raven you get one classloader per artifact (ie. per JAR/POM), you will get one net.sf.taverna.t2.ui.menu.MenuComponent from net.sf.taverna.t2.ui-api:menu-api:0.6 (which the 2.1 beta 2 workbench depends on) - and one net.sf.taverna.t2.ui.menu.MenuComponent from net.sf.taverna.t2.ui-api:menu-api:0.7-SNAPSHOT which probably your plugin depended on directly or indirectly. The problem is that instances of the 0.7-SNAPSHOT-MenuComponent are not implementing the 0.6-MenuComponent interface (classes in Java are compared by name AND owning classloader). This means that if your plugin implemented such a SNAPSHOT-MenuComponent, it would not be recognized as a valid instance by the SPI registry that is discovering implementations of 0.6-MenuComponent - but it would be discovered when looking for the SPI files in META-INF/classes/net.sf.taverna.t2.ui.menu.MenuComponent - hence the error message you got on your stack trace. In fact your stack trace shows a special case because the menu-api includes a few default menu items such as DefaultMenuBar - even if you never touches any of the menu stuff, if you had such a dependency on a wrongly-version-matched menu-api you would get this stack trace, as the second DefaultMenuBar from 0.7-SNAPSHOT is found by the 0.6-MenuComponent-registry - if you're following me. If not, it does not matter. :-) The SPI registry does skip those implementations that don't match, while printing the above stacktrace, but in the end if you are not implementing the 'right' Perspective interface or Activity interface, your plugin would not be able to connect to the rest of the workbench. This is one of the biggest pains of the Raven plugin system and one of the reasons why we are going to move away from it this autumn and winter. Because it is so strict on version numbers in the ends it means that all the version numbers always need to be in perfect match. The problem then is the internal versions in Taverna itself, say we introduce a very tiny addition to the Menu API that codewise should compile and run even with older code. We would then have to give it a new version number so that we can compile, test and deploy that new version of that artifact. Normally in Maven you would then not have to change this version dependency everywhere to pick up the new version of the menu API, only 'at the top'. (Still with potential conflicts as one can disagree about what is the top) But in Raven each POMs version statement is directly followed, each with a separate classloader, so if there's just a single artifact somewhere that depends on the old version of the menu API, it would cause the same error as you reported. Now you might see the recursive problems here - because of the above reasons everything that depends on the updated menu API also needs a new version number, and so on, and in the end we typically end up with every artifact 'below' getting a new version number for a Taverna release. For plugin developers this means that they need to maintain a POM file per Taverna release, and match exactly on all those numbers as well! I did a restructuring of the code for 2.1 that was meant to help a bit on this problem, by introducing a stricter hierarchy such as: raven > core > activities > ui-api > ui-impl > ui-activities/ui-components > ui-exts > external plugins Things on the right are only allowed to depend on artifacts to its left - and occasionally within its own group. (we don't generally allow activities to depend on each other, but different APIs could depend on each other as long as one does not make a loop). This made a bit more of a deal of the split into -api and -impl packages such as menu-api and menu-impl - with the idea being that if you change anything in this tree, you will only need to update the versions there and to the right of the change. So a change to a ui-component such as Workflow Explorer should not affect activity implementations, the workflow model or the workbench APIs, but one would need to give new version number to that particular UI component and other component depending on it (if extensive, the whole ui-components module), and then any affected ui-exts modules as well. It also means that the further out to the right you depend on stuff, the more often you would need to update version numbers. ui-exts was added as a kind of catch-all for the workbench for when we need to depend on say both ui-activity and ui-components at the same time. This is mainly used for shortcut-kind of stuff like 'Add string constant for port' and other semi-external plugin-like additions like the loop support. I've not yet looked at which versions we will need to change for the 2.1 RC 1 release, Alan has said he has updated all the versions to depend on new snapshot versions to get the subversion code to build/run/work, but as this would mean a new version of everything (and a more cumbersome release), we should look at if this is really necessary as it forces even more trouble for plugin developers. What we'll probably do as we stabilise 2.1 RC1 next month is to make the Subversion code use stable versions where we know nothing has changed (and none of their dependencies have changed) - for instance I believe we've not changed anything in Raven or in the workflow model. -- 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
