FWIW: I don't think that there will be a strong need going forward to keep the OJ codebase and the Vivid codebase rigorously separate. The momentum is definitely with OJ now, and I wouldn't expect to see very much if any further independent development to the Vivid codebase. So if maintaining this separation is painful, it may not be worth the pain.
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 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. Paul Austin wrote: > Agree totally, > > In my environment I have the following dependency tree where you can > only access classes up the tree. So the Vivid JUMP should not depend on > Open JUMP, I just did a quick search and there are 21 matches to the > keyword openjump in the com.vivid packages. In these cases either the > reference should be removed on the vivid version deprecated removed and > an openjump version created. > > Vivid JUMP > +- OpenJUMP > +- My JUMP Core > +- My Other Plugins > > One way to enforce this would be to modularise open JUMP and enforce the > dependencies. > > Paul > > Larry Becker wrote: > >> True. The trick is recognizing the difference between reusing code >> and creating dependencies. >> >> Larry >> >> On 9/18/07, Paul Austin <[EMAIL PROTECTED]> wrote: >> >> >>> I think where ever possible we should start to use reusable Utility >>> methods or UI components, there is a lot of local code and classes in >>> JUMP which do exactly the same thing. >>> >>> The biggest case is a whole bunch of ActionListener classes which then >>> call say xxx_actionPerformed on the main class. If you had an >>> InvokeMethodAction that would take a method name and instance and just >>> invoke that method, then you'd save a whole bunch of PermGen memory by >>> having less classes. >>> >>> Paul >>> >>> Larry Becker wrote: >>> >>> >>>> SS, >>>> >>>> If you are already using the other methods in DialogUtil, then don't >>>> worry about it, otherwise why not just keep the method local? >>>> >>>> thanks, >>>> Larry >>>> >>>> On 9/18/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: >>>> >>>> >>>> >>>>> Larry, >>>>> >>>>> Would there be a solution that would work for SkyJUMP? I will be >>>>> putting together an surveyos_openjump_utilities JAR file, and I could >>>>> put a DialogUtil class in there if it is a better fit. >>>>> >>>>> I'm just trying to keep duplication to a minimum. >>>>> >>>>> The Sunburned Surveyor >>>>> >>>>> On 9/18/07, Larry Becker <[EMAIL PROTECTED]> wrote: >>>>> >>>>> >>>>> >>>>>> The only reservation I have is to note that this class exists only in >>>>>> OpenJump. >>>>>> >>>>>> regards, >>>>>> Larry >>>>>> >>>>>> On 9/18/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Does anyone have a problem with my adding a method to the DialogUtil >>>>>>> class? This method would accept a JListBox and a reference to a >>>>>>> LayerManager as arguments. It would then set name of each Layer in the >>>>>>> LayerManager as the values in the JListBox. >>>>>>> >>>>>>> If this method is not appropriate for the DialogUtil class I will put >>>>>>> it in one of my own utility classes, but I was trying to keep this to >>>>>>> an absolute minimum. >>>>>>> >>>>>>> If this method is available as a public method of another class, >>>>>>> please let me know and I will use it instead. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> The Sunburned Surveyor >>>>>>> >>>>>>> ------------------------------------------------------------------------- >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> http://amusingprogrammer.blogspot.com/ >>>>>> >>>>>> ------------------------------------------------------------------------- >>>>>> 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: 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
