Thanks a lot Ian. Could you please let us know the timeline for the adoption of spring and ogsi? I know you already used spring in the platform?
Regards, Wei Ian Dunlop wrote: > Hello, > > Maven lets you define all the jars that your project depends on. This means > that you don't have to ship/store all the jars with your project in lib > folders and also lets you update quite easily since all you have to do is > change the pom file. Maven also makes building and testing easier. > > Spring has lots of different parts but the bit that Taverna uses is the > Dependency Injection/Inversion of Control part that allows 'simpler' > splitting of API ie. interface and implementation. In the spring xml files > you tell it what implementation to use and it finds the required classes. > This means that in your code you only have to refer to the interface so you > can easily change the implementation without having to change the bits of > code that use it. > > Then we have Raven which is the current classloader system used in Taverna > instead of the default bootstrap classloader in Java. It uses the Maven pom > files to find the jars that plugins need and keeps them all separated so > that different plugins can use different versions of the same jars. This is > the part that we are planning to replace with OSGI bundles. > > Cheers, > > Ian > > 2009/9/15 Wei Tan <[email protected]> > > >> Thanks Alan!! :-) And please see my questions inline. >> >> Alan Williams wrote: >> >>> Stian Soiland-Reyes wrote: >>> >>> [snip of good explanation] >>> >>> >>> >>>> hence the >>>> error message you got on your stack trace. >>>> >>>> >>> Wei was "lucky" to get >>> > net.sf.taverna.t2.ui.menu.DefaultMenuBar cannot be cast to >>> > net.sf.taverna.t2.ui.menu.MenuComponent >>> >>> It can also cause exceptions such as >>> >>> "net.sf.taverna.t2.foobar cannot be cast to net.sf.taverna.t2.foobar" >>> >>> [snip] >>> >>> >>> >>>> Alan has said he has updated all the versions to >>>> depend on new snapshot versions to get the subversion code to >>>> build/run/work, >>>> >>>> >>> Yes. In theory, it was only necessary to update the dependencies for >>> things that depended upon modules where we were making changes. In >>> practice, this was very hard to keep track off even for small changes. >>> >>> [snip] >>> >>> >> Again, I would think that as a plug-in developer, maybe I should NOT >> depends on SNAPSHOT jars? >> Because I am not updating the internal structure of the workbench. What >> I need is to use a stable version >> of the workbench and test the functionality of my code. Unless you >> provide some "hot-fix" in SNAPSHOT, >> otherwise I would use the stable version used by T2.1 beta 2 from now >> on. Is that proper? >> >>>> 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. >>>> >>>> >>> I'm not convinced that noting the stability of, say, Raven will help >>> plugin developers much as they will have to update to new versions of >>> "higher level" modules. It will help, though, if a message is sent >>> saying what the new version numbers are. >>> >>> One issue that Stian didn't mention is that version-specific information >>> is not just in the pom files. The Spring extensions that are currently >>> used also specify the version of an artifact. Not getting those correct >>> will also mess up the build (as I know to my cost). They should all now >>> be working with snapshot versions. >>> >>> The Spring configurations should probably be specified as resources in >>> the pom's so that they can pull in the pom's version numbers. That >>> might be done for 2.1. >>> >>> >> Is there any existing document explaining the use of Spring and Maven >> together? With my limited knowledge of >> them I can see that, Maven helps you to load the right jar in the >> class-path and Spring helps you to connect to the >> right child-class (of a more generic one)? I am sure I can easy be wrong >> so please correct me :-) >> >>> The version numbers are also repeatedly specified in the pom's - once >>> for ui-api, once for ui-impl etc. It may be more realistic to push the >>> version numbers up into ui, or even into taverna-workbench or the >>> overall parent pom. That is just my opinion though. >>> >>> Alan >>> >>> >>> >> ------------------------------------------------------------------------------ >> >>> 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 >>> >>> >> -- >> Wei Tan, Ph.D. >> Computation Institute >> the University of Chicago|Argonne National Laboratory >> http://www.mcs.anl.gov/~wtan <http://www.mcs.anl.gov/%7Ewtan> >> >> >> >> ------------------------------------------------------------------------------ >> 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 >> >> > > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > 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 -- 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
