Larry,
Please see my comments below.
SS
You wrote: "I am mostly interested in using the already existing
workbench-properties.xml to allow lib/ext plugins to be added without
the necessity of creating an Extension."
I think this is an idea with merit. I never really understood the point of
the Extension mechanism in OpenJUMP. Why not just load the plug-ins
themselves? Having said that I still have 3 concerns:
[1] I don't fully understand the purpose of the Extension class and would
need to look at it before I could say we should replace it with another
mechanism.
[2] I'm also concerned about OpenJUMP's code base deviating a great deal
from Vivid's JUMP code base. I know differences are the reason why we forked
the code to begin with, but I think we should consider any significant
change from JUMP's code carefully. It might be worth asking Vivid Solutions
if they would be interested in incorporating the changes we are talking
about. It seems like they're a little more willing to share their plans for
the future of JUMP with our community, so we should take advantage of that.
If this were a smaller change I wouldn't be as worried, but the plug-in
mechanism is a fairly major part of what JUMP does.
[3] One great thing about JUMP's current plug-in mechanism is that the user
doesn't have to modify any text files to install plug-ins. They just drop
the JAR file into the /lib/ext folder. This does create a little more work
for the developer, but is easier for the developer. I suppose you could
write an installer for you plug-in that modifies the text file for the user.
Perhaps this wouldn't be to difficult if we set up a utility class that
plug-in developers could use to do this.
I'll let the other developers add their comments.
workbench-properties.xml to allow lib/ext plugins to be added without
the necessity of creating an Extension.
It has been an interesting discussion so far, but to make it
productive I think we clearly need to define some terms more
rigorously. In particular the term plugIn (or plug-in since spell
checkers don't understand camelCase).
As you all know, practically every feature in JUMP is implemented as a
plug-in. I count about 60 of them instantiated at the top of
JUMPConfiguration alone. These plug-in are sometimes lumped in with
what we call the "core" of JUMP. They provide the basic UI and
feature set. Let us call these plug-ins "core plug-ins".
Then there are the plug-ins that are external to the particular JUMP
flavor that reside in the lib/ext folder. These plug-in have UI
installation code present in their initialize() method which is called
by their own Extension class. Let us call these "add-on plug-ins".
As I mentioned, my goal is to use the workbench-properties.xml file as
it is used in the development environment - as a means of
instantiating add-on plug-ins. However, I have no objection to the
idea of replacing the JUMPConfiguration class with another one that
uses a different external XML file to both instantiate and configure
the UI for a core plug-in. This should be fairly easy to do since
JUMPConfiguration.initializeBuildTnPlugIns() already uses reflection
to build a list of plug-ins. All that is required is some UI glue
code and an XML format and reader.
hope this clears up the discussion,
regards,
Larry Becker
--
http://amusingprogrammer.blogspot.com/
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
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 DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
