Paul wrote: "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."
I'm open to this as long as we keep it as simple as possible. :] Paul wrote: "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." I believe these are distributed as part of the core, but Stefan would know for sure. I think they should probably go in the org.openjump package. I would suggest dropping the deeJUMP/Sigle/Pirol root packages for code in the core. I've brought up the package naming/hierarchy topic before. Please see: http://openjump.blogspot.com/2007/04/openjump-package-naming-convention.html http://openjump.blogspot.com/2006_12_10_archive.html Paul wrote: "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." I absolutely agree. This is a great idea. 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? 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. :] 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. 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
