Yes, makes sense to me. Using package hierarchy definitely seems like
the way to document/enforce/promote the modularization strategy.
I can't comment on Maven's impact on this, but it seems to me like the
modularization is orthogonal to the use of Maven. Maven probably makes
it easier to bu
Martin,
Eventually I will see the need for further separation as we add
different reusable libraries under the openjump banner such as the
DataObject framework. By using maven with its dependency management we
can slowly add further modularization as it makes sense. There will also
ben reusable UI
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
maintainin
Or Alternatively we ditch the JUMPConfiguration with an Openjump
equivalent sub class.
Paul
Stefan Steiniger wrote:
> ok.. but some of the improvements need to be referenced in the original jump
>
> a) menu functions that need to be initialized in JUMPConfiguration
> b) the link to OpenJUMP conf
ok.. but some of the improvements need to be referenced in the original jump
a) menu functions that need to be initialized in JUMPConfiguration
b) the link to OpenJUMP configuation
c) functions that add something to existing dialogs (i imagine the style
dialogs)
stefan
Paul Austin schrieb:
> Ag
> One way to enforce this would be to modularise open JUMP and enforce the
> dependencies.
I suppose this is doable by making OpenJUMP a separate plugin jar.
We do kind of need to formalize some guidelines on this. I just
created the SelectablePlugIn similar to the vividsolutions
EditablePlugin
Landon,
Can you paste the implementation of the method?
Cheers,
Paul
Sunburned Surveyor wrote:
> Paul 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."
>
Paul 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."
This is my goal Paul. Thank you for putting it so concisely.
Larry wrote: "The trick is recognizing the dif
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
ref
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
> J
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
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
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
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
> Layer
14 matches
Mail list logo
