@Michaël
> Interesting. What kind of test ?
Three kinds of tests: (1) for the dialog using a GUI robot with FEST-Swing,
(2) for the plugin functionality and (3) for unittests of components used
by plugins. I write these tests BDD-style using Spock and Groovy and run
them with JUnit within Eclipse or an continues integration server that
calls an ant script.
> I often start my plugins with small beanshell scripts (to understand how
jts functions work before starting a plugin for example)
Me too. This is my preferred way to experiment a bit and incubate my
PlugIns. Experimenting is either possible with (1) whole script files or
(2) within the Python REPL. I use latter very rarely.
@Ede
> the intended way to develop extensions with plugins is afaik like this:
Ok, I stumpled upon the workbench-properties.xml when I made the list of
all plugins, but never used the xml file for my plugins, since I never use
FeatureInstaller or PlugIn.initialize(), i.e. I initialize my plugins in
the Extension.
@Stefan
Thanks for the link to the wiki. Never thought about using a run
configuration in Eclipse to start OpenJUMP with my plugins. It's also
possible to configure the environment in Java source code instead of a run
configuration.
String[] myArgs = new String[] {
"-plug-in-directory", "lib\\ext",
"-default-plugins", "default-plugins.xml",
"-properties", "workbench-properties.xml",
"-i18n", "en"
};
JUMPWorkbench.main(myArgs);
My main focus is currently to write some guidelines on how to write tests
for all the plugins in the tools menu and eventually refactor them
(mercilessly). Thus we need to run unittests easily via Eclipse and a whole
WorkbenchFrame.
2012/1/3 <edgar.sol...@web.de>
> On 03.01.2012 10:44, Stefan Steiniger wrote:
> > Its not truly dynamical and does not work for GUI changes, but for
> > algorithms (and when class variables inside the plugIn class don't
> > change) I can modify code live in Eclipse Debug Mode.
> >
>
> if i always recreate gui components (for testing) i can even change the
> gui during runtime
>
> >
> > PS: sorry, seems like we really should expose the developer primers
> > better - or write a downloadable manual.
>
> i took it from the original vividsolution plugin developer guide. that
> should still be available somewhere.
>
> ..ede
>
>
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
