Sunburned Surveyor wrote: > > Martin wrote: "It would still be worth having a well-defined strategy > for what can > depend on what. I would suggest a further partition within OJ itself: > > core non-UI components > - core Workbench components > -- plugins" > > This is a good idea. I believe this was the original goal with the > JUMP-API JAR file and the JUMP-Workbench file, was it not? > Yep. > Marint wrote: "I would even suggest that some plugins should be split > between Workbench and non-UI components, to allow easier reuse of the > non-UI code. This > also encourages a MVC coding style, which often pays off in the end." > > Are you talking about having the code for the same plug-in in > different JAR files? I'm confused. :] > Not necessarily. I'm really suggesting that "large" plugins should be split into GUI and non-GUI parts (View/Controller and "Model"). Really this is just common-sense factoring. It sometimes is nice to pull out common spatial functionality into a separate (core) packaged - but this area gets pretty grey pretty quickly. As a start both Model and View can live in the same package. > I do think the separation of GUI and non-GUI code is a good thing. For > example, JUMP uses the addition of a JFrame to determine when as task > is added. To me it would have been much better to have a non-GUI event > like "TaskCreated" to indicate this had occurred. Ties to GUI > components and GUI events make it very hard to unit test plug-in code. > Yes, agreed. I think what you are saying is that the Workbench should be clearly split into Model and View modules. Whereever possible, functionality should be defined in terms of the Workbench Model, not Swing GUI components. The View can depend on the Model, but not vice-versa (standard stuff....)
Hmm... It would be nice to have a box diagram which shows the various modules in the system and their interdependencies. The diagram could also show the relevant parts of the package hierarchy and the dependencies. (Paul, you're a diagramming whiz - any other suggestions?) I did a diagram like this way back for my early presentations on JUMP - it could easily be updated. It would also be useful to show a finer level of granularity, showing the major subsystems in JUMP and how they are packaged. Eg. the Imagery Framework, Datastore framework, Registry, CursorTools framework, etc etc. There's a lot of modularity in JUMP by design - it helps to see it diagrammed. > The Sunburned Surveyor > > > > On 9/18/07, Paul Austin <[EMAIL PROTECTED]> wrote: > >> In one of the other threads we have talked about the modularization of >> code so I thought I'd start a thread on the topic. >> >> To do this I think that we need to move to maven as the build system as >> it can help with the multi module builds and cross module packaging. >> >> We would need the following modules >> >> * vivid-jump >> * openjump-core >> * >> >> * geotools >> * tiff (geotiff and libtiff) >> >> Are the dee jump and pirol plugins distributed as part of the core? If >> they are then we should either merge them into the org.openjump package >> or have them as a separate module. >> >> We'll also need to distinguish between "core" libraries, these are the >> ones above and "extension" libraries. The distinction will be that the >> core libs go into the lib dir and everything else goes into the lib/ext dir. >> >> Paul >> >> >> ------------------------------------------------------------------------- >> 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 > > -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 ------------------------------------------------------------------------- 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
