[JPP-Devel] R: Major Refactoring Of OpenJUMP Begun
I read your blog and, as always, it has a distinctive courageous taste, so I really hope you can attain your proposed goals!!! Here follows my modest opinion (I'm not subscribed to blogspot). I'm very sorry because I don't contribute to OJ at all, while you are spending lots of energy in it!!! So please don't waste too much time with me and follow your istinct (...use The Force...). Bye Paolo Rizzi .) Extraction of OpenJUMP RCP code. .) Extraction of a OpenJUMP model library. .) Improve the separation between model and view. These are _very_important goals!!! It would be great if OJ could be turned into a server application too. Imagine the catalog, data accessing, rendering and maybe a few other components running on a server. There may be a WMS adapter (you may call it whatever you like) on the same server using it so any WMS client can be used. Or there may be a native OJ Ajax adapter talking to a native OJ client. Maybe the very same OJ desktop app could be used to connect to an OJ server through some form of remoting system. The beauty of it is that you can design your tasks and their apperance using the OJ desktop app and the very same task files can then be transferred on the OJ server app to be available remotely. .) I know you're not very akin with using third party libraries, but in this big refactoring the plugin managing system may be revised too. I don't know how far you went with your plugin-dependency system, but remember there exist a lot of available open-source Java containers that can be used in place of the existing plugin loading system. Each of those container is supported by a strong and specialized development community, so adopting one of them would give OJ more robustness, performance, functionalities and most of all it would offload work to other people ;-) To name a few: Spring, PicoContainer, Apache HiveMInd, JBoss Microcontainer, etc. I'm not an expert in open-source licences, but I think at least one of those should be compatible with OJ. .) Support for low-RAM architecture. .) ...A default FeatureCollection implementation that is spatially indexed and writeable... It may be worth while to investigate existing open-source Java caching libraries (JBoss Cache, for example). Those system should help in trasparently managing large quantities of data using whatever little RAM is available plus disk space. I think (not sure though) they let you completely forget where data is and concentrate on using it. Surely enough they may not tailored for spatial data, though... .) And just to make you hate me wholeheartedly ( :-) another place where OJ could use a third-party library is in native data-storage. I remember you were working on a OJ binary file format and here again remember there exist open-source Java SQL databases that are able to use some form of binary files to store data, if needed. I don't know how good they're with spatial data, but they may also help with the previous point, because they may incorporate some form of caching. -Messaggio originale- Da: Sunburned Surveyor [mailto:[EMAIL PROTECTED] Inviato: mercoledì 10 dicembre 2008 22.18 A: OpenJump develop and use Oggetto: [JPP-Devel] Major Refactoring Of OpenJUMP Begun Not in the JPP SVN, but in my own fork. :] If you are interested in what is involved, you can read more on my blog: http://openjump.blogspot.com/ If anyone has suggestions on how I can design the architecture so that docking window frameworks would be pluggable, I'd be interested to hear them. This would allow me to switch out the docking window framework in the future if our core group decides to go a different direction. The Sunburned Surveyor -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009 .visitmix.com/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Building JTS from CVS for OJ Nightly Build
Hi SS, I think we should wait for Michael to respond. He may choose to do the other workaround of converting LinearRings to LineStrings. Larry On Thu, Dec 11, 2008 at 11:27 AM, Sunburned Surveyor sunburned.surve...@gmail.com wrote: If I get a build of the latest JTS CVS can we get replace the current JTS library in our nightly build? I think this will fix the planar graph bug that was reported. SS -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- http://amusingprogrammer.blogspot.com/ -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Building JTS from CVS for OJ Nightly Build
Ok Larry. I missed that part. In the meantime I've got the CVS for JTS plumbed into my Eclipse install and I'm currently working on getting the build file to run. So I shouldn't have any problems building the new JTS jar file for the OJ NB. SS On Thu, Dec 11, 2008 at 9:30 AM, Larry Becker becker.la...@gmail.com wrote: Hi SS, I think we should wait for Michael to respond. He may choose to do the other workaround of converting LinearRings to LineStrings. Larry On Thu, Dec 11, 2008 at 11:27 AM, Sunburned Surveyor sunburned.surve...@gmail.com wrote: If I get a build of the latest JTS CVS can we get replace the current JTS library in our nightly build? I think this will fix the planar graph bug that was reported. SS -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- http://amusingprogrammer.blogspot.com/ -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Building JTS from CVS for OJ Nightly Build
well.. I would wait and include a final JTS version. Btw. why do you think it will solve the graph bug? stefan Sunburned Surveyor wrote: If I get a build of the latest JTS CVS can we get replace the current JTS library in our nightly build? I think this will fix the planar graph bug that was reported. SS -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Major Refactoring Of OpenJUMP Begun
Hi Landon, Every suggestion you make in your blogspot makes sense to me. They are not easy tasks and I'm not particularly optimistic about our ability to achieve only one of them, but let's say that tomorrow, we get ten new contributors, ready to spend as much effort as you do on the project :-) docking framework : I just know that developpers from jEdit project have improved their previous docking architecture which now support several docking framework through plugin implementations (a plugin for MyDoggy has been developped, others can be added). I give you the link, I'm not able to comment it http://jedit.wiki.sourceforge.net/Docking+framework?f=print Extraction of OpenJUMP RCP code, extraction of OJ's model, improve the separation of model and view : each proposition seems good to me. Some important parts of OJ architecture are already clearly identified through packages (feature package, model package). I think there are tools around there to evaluate the dependency between packages inside a project. What about the division of the plugin collection into com.vividsolutions plugin and org... plugins ? Migrating existing code to java 5 seems a big task. I agree it would make the code more readable. Some packages are probably better candidates (again : feature package with attribute types, feature collection...), but it may be difficult to migrate only a part of the project. Low-ram architecture : I think that creating a reader which doesn't load every thing in memory is not too difficult (some plugins have already been done by developpers like A. Zabala from agile/gvsig). What is more difficult is to read from disk, to manage changes in-memory, and to commit in-memory changes back to disk (I think saig/kosmo has such a transactionnal system). Thanks to Paolo which added precious comments to your post. my 2 cents Michaël** Sunburned Surveyor a écrit : Not in the JPP SVN, but in my own fork. :] If you are interested in what is involved, you can read more on my blog: http://openjump.blogspot.com/ If anyone has suggestions on how I can design the architecture so that docking window frameworks would be pluggable, I'd be interested to hear them. This would allow me to switch out the docking window framework in the future if our core group decides to go a different direction. The Sunburned Surveyor -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Major Refactoring Of OpenJUMP Begun
I want to respond in more detail to you and Paolo. Let me just say this for now: - I'm not talking about rewriting every class in the core. That would definitely be a major feat. I will likely only touch the code that I interact with as part of my integration of the docking window framework. - My change to support low-RAM architecture will only be to the interface of the FeatureCollection. I'm not talking about providing an implementation that caches features on disk. Not yet. I do have some existing FeatureCache code that I worked on while I was sick with the flu, but I'll keep that separate for now. It needs to be modified anyways, as I set it up to work with the existing architecture by using FeatureFacade objects (proxies) to keep a lightweight Feature implementation in memory. If I make the change to the FeatureCollection interface that will no longer be necessary, and it will greatly simplify the FeatureCache code. I realize my greatess weakness is trying to do too much, and never getting even a little bit done. So I'm going to look at the list on my blog post and see where I can scale the refactoring back. I've decided I won't add any new features during the refactoring except for the docking windows framework, the other stuff can wait. If I don't tell myself no, the refactoring will never get done. I really hope the refactoring will make OJ a viable platform for a few more years into the future. I think future refactorings like this will be needed as the Java language and the underlying computer technology changes. I believe we must continue to refine the architecture of OJ to keep up with these changes or the program will slowly die. Perhaps I am wrong about this. There may be a lot of really old programs that are still being used by a loyal user base. SS On Thu, Dec 11, 2008 at 3:19 PM, Michael Michaud michael.mich...@free.fr wrote: Hi Landon, Every suggestion you make in your blogspot makes sense to me. They are not easy tasks and I'm not particularly optimistic about our ability to achieve only one of them, but let's say that tomorrow, we get ten new contributors, ready to spend as much effort as you do on the project :-) docking framework : I just know that developpers from jEdit project have improved their previous docking architecture which now support several docking framework through plugin implementations (a plugin for MyDoggy has been developped, others can be added). I give you the link, I'm not able to comment it http://jedit.wiki.sourceforge.net/Docking+framework?f=print Extraction of OpenJUMP RCP code, extraction of OJ's model, improve the separation of model and view : each proposition seems good to me. Some important parts of OJ architecture are already clearly identified through packages (feature package, model package). I think there are tools around there to evaluate the dependency between packages inside a project. What about the division of the plugin collection into com.vividsolutions plugin and org... plugins ? Migrating existing code to java 5 seems a big task. I agree it would make the code more readable. Some packages are probably better candidates (again : feature package with attribute types, feature collection...), but it may be difficult to migrate only a part of the project. Low-ram architecture : I think that creating a reader which doesn't load every thing in memory is not too difficult (some plugins have already been done by developpers like A. Zabala from agile/gvsig). What is more difficult is to read from disk, to manage changes in-memory, and to commit in-memory changes back to disk (I think saig/kosmo has such a transactionnal system). Thanks to Paolo which added precious comments to your post. my 2 cents Michaël** Sunburned Surveyor a écrit : Not in the JPP SVN, but in my own fork. :] If you are interested in what is involved, you can read more on my blog: http://openjump.blogspot.com/ If anyone has suggestions on how I can design the architecture so that docking window frameworks would be pluggable, I'd be interested to hear them. This would allow me to switch out the docking window framework in the future if our core group decides to go a different direction. The Sunburned Surveyor -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The
