On 7/23/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > Harvey, > > I see you have already received a welcome from some of our active > developers. I believe that they have done a good job answering your > questions. I also want to welcome you to our mailing list. I'd love to > know what context you are using OpenJUMP in, if you are willing to > share that. Also, it would be great to know if there are particular > aspects of the program that you are interested in working with. >
Well, my interests lie in doing some analysis of demographic trends in the greater Vancouver (BC) area. I'm moderately familiar with Arcview/Mapinfo but was looking to build a more intensive growth model that will need an easier way of doing the spatial parts. I'm a pretty decent C/C#//Java coder, and this looked like a promising project. I've implemented some fairly large modelling projects in Java in the past few years (one just passed the 80k lines of code). > Let me share some brief thoughts on one of your questions about the > org.openjump and com.vividsolutions package names. > > Harvey wrote: > > "Which could be preserved with shell classes extending classes under > the org.openjump namespace. I agree that it would be a bad idea to > just break compatibility for the external plugins on a whim, but as an > ongoing project doesn't it make sense to start moving towards a > unified 'core'? As things prove useful they could then be pulled in > and projects could begin to rely on an openjump core?" > > Some of the other developers have already mentioned that a lot of our > plug-ins depend on the existing com.vividsolutions name. This could > probably be fixed, or hacked around, but one problem is that we don't > do a great job keeping track of the plug-ins available for OpenJUMP. I > need to do a better job of this. That's the impression I have now, I wasn't initially clear on how heavily plugin-based the project was, compatibility would be paramount. > > Here is my philosphy on the reason we are using the current package > naming scheme in OpenJUMP: > > The packages under com.vividsolutions contain legacy code from the > original JUMP program upon which OpenJUMP is based. Source code in > these pacakges is the original JUMP source code, or the original JUMP > source code with only very small modifications, improvements, and bug > fixes. (This code has also been internationalized, which was not done > in the original JUMP.) > > The packages under org.openjump are packags for OpenJUMP's core that > are entirely new, or that totally revamp a class or set of classes > from the original JUMP. This is code in the core that we've really > messed with. :] > > There are a number of other packages that contain plug-ins by > third-party developers. As a general rule, we encourage developers to > use OpenJUMP's plug-in model, rather than making modifications to the > core. This means OpenJUMP's source code will contain more top-level > packages than most standard programs. Thanks for that, it seemed there was a rather large number of packages. I'll continue to look around at the code, and keep in touch if I have any more questions/suggestions. > > I hope this system makes sense to you. I'm not saying that it can't be > improved, but it has been getting us by. I believe part of the reason > we maintain the pacakges under com.vividsolutions is to provide > separation between legacy JUMP code for the core, and new code for the > core. > Thanks much, looking forward to getting my feet wet. Harvey ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
