Stian: thanks a lot for your long and useful reply! :-) Stian Soiland-Reyes wrote: > > 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. > 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) > 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. > You introduced <property/> in Maven to keep version number synchronized across poms, right? 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, 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. I hope you catch what I mean here... > 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). > 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. > > 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. > > >
-- 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
