I am doing some prototyping on the process api and JGrass processing modules and I have to say I find the api quite invasive, given the fact that it should lead people to bring their algorithms to be compatible with geotools.
Following the new process implementation link [1], I have some comment, to which it would be great to have some back-comment. - the fact that I have to extend a class instead of implementing an interface is a bit strange to me - the fact that i am forced to create a factory class and even pass it to my module constructor, also In fact it looks far to much work to me to make modules compatible with all this. Are there working examples of someone that migrated many modules to the process api? With Sextante it went the way round, right? I guess they didn't adapt to the process api. Any comments are welcome, in the meanwhile I will look out to find if the factory and process can be generated somehow from annotations. Cheers, Andrea [1] http://docs.codehaus.org/display/GEOTDOC/Implementing+a+new+Process On Sun, Mar 14, 2010 at 3:46 AM, Michael Bedward <michael.bedw...@gmail.com> wrote: > On 14 March 2010 13:01, Jody Garnett <jody.garn...@gmail.com> wrote: >> Ah that is just it - not supposed to run the process in the event thread :-) >> > > I'm proud of my continuing ability to discover most of the mistakes > that one can make with GeoTools. > > I'm using SwingWorker in the example now (not committed yet) and it's > quite neat because it keeps the multi-threading, task polling etc. > from obscuring the point of the example. > > However, there's still a problem with the progress window not > updating. I discovered that the RasterToVectorProcess never actually > starts the progress monitor :-( Fixed that but it still doesn't > update properly, even though I give it a task that takes a few seconds > to run. I don't think I understand SubProgressListener. > > Michael > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel