Some More Thoughts On Supporting Plug-In Dependencies

I had some more thoughts this evening on supporting Plug-In Dependencies. In the system I described in my last blog post participation of a plug-in in the dependency system could be totally voluntary. We could require that participating plug-ins add themselves to a list or collection of participating plug-ins stored in OpenJUMP. They could do this from within their initialization() method.

I also realized that passing an event with simply a list of the loaded plug-ins to the plugInsIntializationCompleted() method will not be sufficient. We will acutally need to pass a reference to each participating plug-in so the plug-ins that depend on them can obtain a reference to the instance object representing the plug-in on which they depend. It doesn't do much good to have a dependency system if plug-ins can access the public methods of the other plug-ins on which they depend.

The Sunburned Surveyor

Read More

Supporting Plug-In Dependencies In OpenJUMP

I was giving some thought this afternoon to how we might support plug-in dependencies in OpenJUMP. (A plug-in dependency means that one plug-in requires that another plug-in be installed and initialized before it will work.)


I really want to avoid a complicated system with a lot of overhead. The plug-in system in Eclipse is an example of this. (I’m not saying that the plug-in system in Eclipse doesn’t work very well, because it does. I do almost all of my Java programming in Eclipse.) One of the things I’ve always admired about JUMP/OpenJUMP is the simplicity with which the program can be extended.

In OpenJUMP’s current design Plug-Ins must implement the initialize() method. This method is called by OpenJUMP when the plug-in is loaded into the program. (A plug-in that is loaded into OpenJUMP doesn’t usually perform any tasks for the user at that point. It is just “initializing” or setting itself up for use. In my humble opinion a Plug-In should do as little work as possible in the initialization() method. This will keep OpenJUMP’s memory footprint and start-up time as small and as short as possible.) In this current system I have no way to design a plug-in with classes or interfaces that depend on classes or interfaces in another plug-in. If you want to use a class or interface in your plug-in code you have to include it in your plug-in or make modification of the core. This isn’t the best system, as it means most plug-ins can’t be designed to be extendable themselves.

An example of this is when I first began working on OpenJUMP’s CursorTools. I wanted to have a class that could be used to manage the active or current CursorTool, and that provided utility methods to this CursorTool. I wanted this class to be loaded as a plug-in, but to be available to other CursorTool plug-ins. How do you do this without support for plug-in dependencies or modifications to the core? There might be a hack, but it would be ugly.

Here is my idea for one solution to supporting plug-in dependencies in OpenJUMP. Remember that this is just an idea. I haven’t thought it completely through, and I’m sure there are alternative solutions that we can consider.

We will add a method named plugInsInitializationCompleted() to the PlugIn interface and the AbstractPlugIn class. This method will be called on each plug-ins after all of the plug-ins have been loaded. This method will be passed an object that contains an array or Collection of identifiers of the plug-ins that have just been successfully loaded and initialized by OpenJUMP. If they need to verify a dependency, plug-in developers can, within this method, check the list to make sure the plug-in they are dependent on was successfully initialized. If it was not, they can produce a warning to alert the user, or they can disable their plug-in.

This system works on the principle of “event-based” programming. Each plug-in is an event listener, OpenJUMP is the event broadcaster, and we have an event that indicates plug-in initialization has been completed.

This system will avoid the need of external files that define plug-in dependencies. Each developer will add that logic to the plugInsInitializationCompleted() method of their own plug-in implementation.

The Sunburned Surveyor

Read More

Update On OpenJUMP-Ex Release

I finally mastered my Ant build file and was able to get some JAR files for OpenJUMP out of Eclipse. I've got everything set for the first release of OpenJUMP-Ex. After we've tested this release for a few months I'll see if I can't get it pushed down as a regular release of OpenJUMP.

I am having some trouble getting the JAR files to execute properly. As soon as I can get this problem fixed I'll get the release on the SurveyOS SourceForge Project Web Site for others to download.

The Sunburned Surveyor

Read More

Some More Thoughts On The Collaborative Development Of OpenJUMP

I am pleased to report that I received some positive feedback about having more collaborative development of OpenJUMP. I heard from at least 2 or 3 different groups that are working with OpenJUMP that said they would be interested.

Some of the developers I spoke to seem to be pushing the idea of a merged core. This issue has come up before, and I have discussed it on my blog. I want to revisit it again in the context of this discussion on collaborative development.

I would first like to say that I think the idea of a “merged” OpenJUMP core that could be used by several different JUMP branches would be a great thing. I think we should have that as our eventual goal at the JUMP Pilot Project. Notice that I said “eventual” goal. I believe it would be a mistake to rush into cobbling together chunks of code and bonus features from all the different JUMP brands out there. I don’t say this as a criticism of the work of those brands developers. But I do think there are some real dangers about breaking things in OpenJUMP if we were to embark on that course. We need to remember that stability is a very important feature of OpenJUMP, and one that we want to preserve.

I’d like to propose the following steps in our course of action to encourage more collaborative development of OpenJUMP, keeping in mind our long-term, not short-term, goal of merging the cores of the different OpenJUMP/JUMP brands.

[1] Establish a package naming convention for Java Packages that can be followed by participating projects and developers.
[2] Finalize the Core Changes Proposal.
[3] Create a section on the JUMP Pilot Project Wiki for collaborative development. This section of the wiki will store a Java Package Map and change history for each of the participating projects. It will also identify current changes that have been made to the core that the project developers feel should also be made to OpenJUMP’s core.

It will probably take me a few weeks to get those 3 steps accomplished. After this has been done we can begin to examine, one at a time, the changes in each “brand’s” core that we would like to make to OpenJUMP’s core. When a project wants to implement a new change, they will have the choice of making a proposal to implement the change in OpenJUMP’s core.

I am prepared to maintain the wiki section on collaborative development with a little help from each participating project. I am also prepared to write the Core Changes Proposal for each change we would like to make in OpenJUMP’s core for other developers to review.

After a few months of this process, I think we will be at a point where many development teams of the JUMP “brands” feel they can migrate completely to OpenJUMP’s core. On the other hand, I can see many reasons why a team would want to maintain their own separate core, as this would allow for somewhat faster development.

The Sunburned Surveyor

Read More