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.
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. 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. 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. The Sunburned Surveyor On 7/19/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote: > ups.. i did not thought about the plugins. > they would be really a major issue, as there should be a lot of plugins > outhere (actually i estimate that our university research group only has > developed 50 plugins which would be hard to change). but this holds > probably only for the com.vividsolutions code > > stefan > > Stefan Steiniger schrieb: > > Hei Harvey, > > > > we welcome you (and others) on the list > > > > Harvey Harrison schrieb: > >> I'm new to the list and was wondering how welcome patches would be to > >> do some codingstyle / pachage name cleanup? > >> > >> Is there a standard codingstyle accepted for the project? > >> > >> Is there any move afoot to unify under the org.openjump.* namespace > >> and remove the com.vividsolutions, etc namespaces to make things more > >> coherent. Would such changes be welcomed? > >> > > > > our last decissions (one may correct me here) has been that we don't go > > for code style standards, since everybody has his own preferences. A > > further, and more important reason, is that such small changes in the > > code make it very hard to keep the sources in sync and update new > > features among different projects (e.g. JUMP, OpenJUMP, SkyJUMP, SIGLE). > > > > Similar things hold for the renaming of packages. Of course a > > unification is a plus and should be considered for the future (in one > > year???), but it makes updating between projects unnecessary diffcult. > > The current style also provides hints for programmers for the original > > sources. > > I hope on your understanding? > > > > But suggestions, bug-patches, reviewing, ... i.e. any feedback is highly > > appreciated. > > > >> Also, any pointers to some low-hanging fruit a new developer could > >> help with to get familiar with the project? > > > > puhh.. thats a tricky question ;) > > Here it would be nice to know your skills or background (for instance we > > have only very few people that are familiar with threading for GUI > > functionalities, but also database specialists or GIS analysis, raster > > tools specialists are sought) > > > > currently people contribute "uncoordinated". That is everybody does what > > he things is of interest in his own work/project. > > A rule is that we try to do as less core changes as possible and favour > > if new functionality is delivered by use of the great plugin concept. > > Changes of the core have to be discussed on the list, before any commit. > > > > For direct inputs on "fruits" i would refer to our bug and feature > > request lists on sourceforge, as well as to this section on the wiki: > > http://openjump.org/wiki/show/Future+Developments > > (but i must admit, that some of the issues are rather old) > > > > so finally my general answer would be, tell us (i.e. the list or in a > > personal email*) what is your (programming) background and/or what is > > your specific interest. > > The top ranked things to do, are related to an OpenJUMP 1.2 release - > > which inludes even some non-dev-todos like documentation (Peppe has a > > go on it) and creating windows-installer-versions (i think Paul put some > > hands on, and SkyJUMP has already a quite well working windows installer) > > > > BTW: if you are a mac-osx-user and developer then we may have specific > > challenges for you ;) > > > > cheers, > > stefan > > > > > > *) people who have contributed since a long time to the project (i.e. > > have a well-founded knowledge on source-code and the project), are: > > Michael Michaud, Larry Becker, Sunburned Surveyor and I. The designer of > > JUMP, Martin Davis, and original JUMP programmers, Jon Aquino and David > > Zwiers, are also watching this list. > > > >> Cheers, > >> > >> Harvey Harrison > >> > >> ------------------------------------------------------------------------- > >> This SF.net email is sponsored by: Microsoft > >> Defy all challenges. Microsoft(R) Visual Studio 2005. > >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > >> _______________________________________________ > >> Jump-pilot-devel mailing list > >> Jump-pilot-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > >> > >> > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2005. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Jump-pilot-devel mailing list > > Jump-pilot-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------- 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
