Here's my thoughts on a couple of these topics...
* I agree with keeping dependencies as small as possible. This
especially applies to "the core". The core could actually be thought of
as a few concentric rings of things: the Feature API, the I/O framework
(and drivers, including DB drivers) the Workbench and plugin framework,
the GUI, and finally all the various extra plugins. With reference to
inode, I'd worry about introducing a dependency for such an important
part of JUMP (the GUI). What happens if inode is no longer maintained?
Once that road is followed for any distance it's pretty hard to go back.
* In one of the last versions of the Vivid JUMP we split the codebase
into 2 jars, core and workbench. The idea was that the core was
independently useful for straight Java coding. This is similar to the
GeoTools/GeoServer split.
* Without knowing more about the impacts on the development process, I'd
say I'm not really in favour of introducing Groovy into the core JUMP
codebase. It seems like it might complicate coding (especially for
people who don't grok Groovy). It seems like it might complicate
upgrading to new versions of Java (how well does Groovy track Java?).
And does Groovy have limitations in support by the various popular
IDEs? It would be nice to have OJ easily used by any Java coding
environment.
If there's really things for which Groovy is essential, could they go
into a separate extension?
Martin
On 3/17/2011 2:00 PM, Benjamin Gudehus wrote:
Hi Michaël,
Thanks for your comments and links to docking and plugin
libraries/frameworks.
is infonode totally free and opensource ?
InfoNode Docking Windows is under GPL. It looks quite good (as one can
see in my screenshots) and has a nice API.
One idea I had which may be related to the plugin management is
that OpenJUMP should be able to record plugin actions in macros.
Here's my basic idea.
void execute(Map<String, Object> macroOptions) {
Map<String, Object> optionsForExecute = null;
if (macroOptions) {
optionsForExecute = macroOptions);
} else {
optionsForExecute = Dialog.showAndReturnUserSelection()
// save optionsForExecute with MacroRecorder.
}
// use optionsForExecute to do something.
}
I'm afraid by the addition of a new library for each single
enhancement. [...]
I agree.
I think that keeping a small API and few dependencies is one of
the best chance for OpenJUMP to keep its place in the OpenSource
GIS ecosystem
Here are some greps listing all dependencies between source files and
jar-files in OpenJUMP.
http://pastebin.com/Npn26PKu
I played around a bit with it and ended up removing 50% of the
dependencies. The lend me to the idea of spliting OpenJUMP into
several jars: openjump-core.jar, openjump-scripting.jar (jython, bsh),
openjump-raster.jar (jai, ...), openjump-gml-svg-sld.jar (batik,
xml-apis) and openjump-postgis.jar (postgresql).
Just a small idea to minimize dependencies for openjump-core.jar.
- polyglot project java/groovy : I'm not a groovy user (just a
beanshell fan). I think a good enhancement would be to make
scripting in any java compatible sripting language easier. I'm not
in favour of mixing java and groovy in core parts of the project
(or UI). But maybe you have strong arguments, or maybe I
misunderstood what you mean with "create a polyglot project with
Java and Groovy"
I like the idea of keeping the core in Java and create a new project
file (thus a separate JAR-file) for the UI. The source code of the UI
could be in Java and Groovy.
Some words to Groovy: Groovy acts the _same_ as Java (i. e. it
compiles to .class files), just without unneccessary ceremony. I use
it throughout my OpenJUMP extension (no single line is in Java). You
even can rename the extension of a .java file into .groovy and it will
compile fine (i. e. java syntax is actually a subset of groovy syntax).
Groovy can also used for scripting in applications (just like Jython,
JRuby or BeanShell). But I don't prefer to do that with Groovy.
--Benjamin
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
No virus found in this message.
Checked by AVG - www.avg.com <http://www.avg.com>
Version: 10.0.1202 / Virus Database: 1498/3512 - Release Date: 03/17/11
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
