Happy new year!
I did some research on the refactoring of the PlugIns in the tools menu and
want to discuss some points:
1. Software development process
2. Legacy code and testing
3. Separation of GUI and code
Let's start with the first point, since I really like to know how you guys
development cycle is.
When I started with OpenJUMP back in April 2009 I typically started Eclipse
and opened my Project with an Extension class and some PlugIns. To test
changes I had to run an ant task to compile the classes and deploy the jar
to the /lib/ext/-directory. Then I started OpenJUMP to execute the PlugIns
via the menubar.
That was tedious.
After a while I started to write unit tests and thus needed to build a
WorkbenchContext outside of OpenJUMP to run these tests within Eclipse.
That made my developement cycle (edit-compile-run/test/debug loop) much
shorter.
The third step was to make the development cycle even shorter, by run
PlugIns dynamically within OpenJUMP. I intent to modify the PlugIns so that
you can edit them within Eclipse (or your favorite editor/IDE) and run them
within an already started OpenJUMP instance. Or to edit them
within Michaëls script editor directly within OpenJUMP and them
directly. It is also possible to run JUnit-Tests within OpenJUMP to load
Shapefile-Fixtures for the tests.
I will spread my thoughts about point two and three later.
Regards,
Benjamin
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
