Re: [JPP-Devel] General refactoring of OpenJUMP

Yes, that's pretty good. I have some time in the next couple of days to write some tests classes. 2012/1/26 Landon Blake > Thanks for explaining Benjamin. I understand now. Smart move using > your framework to create the Workbench instance for testing. I will > need to check that out. > > Landon

Re: [JPP-Devel] General refactoring of OpenJUMP

Thanks for explaining Benjamin. I understand now. Smart move using your framework to create the Workbench instance for testing. I will need to check that out. Landon On Wed, Jan 25, 2012 at 7:57 AM, Benjamin Gudehus wrote: > Hi Landon! > > 2012/1/22 Landon Blake >> >> >> One of my challenges wh

Re: [JPP-Devel] General refactoring of OpenJUMP

Hi Landon! 2012/1/22 Landon Blake > > One of my challenges when trying to unit test parts of the OJ core > previously has been the number of inter-dependencies. Did you come up > with a mock or stub for WorkbenchContext? I really see some value in > sharing mocks and stubs for OJ core components

Re: [JPP-Devel] General refactoring of OpenJUMP

Benjamin: This has been a hard thread to follow, but it sounds like you've been doing some good work on unit testing and reducing plug-in dependencies in OpenJUMP. You wrote: "After a while I started to write unit tests and thus needed to build a WorkbenchContext outside of OpenJUMP to run these

Re: [JPP-Devel] General refactoring of OpenJUMP

thanks! hopefully i'll have time to play with it during the year. when it comes to junit all i know is, it exists ;) thx agn.. ede On 13.01.2012 12:42, Benjamin Gudehus wrote: > Up and running! > > 2012/1/13 Stefan Steiniger mailto:sst...@geo.uzh.ch>> > > sorry for the late reply. > Yes

Re: [JPP-Devel] General refactoring of OpenJUMP

Up and running! 2012/1/13 Stefan Steiniger > sorry for the late reply. > Yes I think its fine to commit this - unit tests are a good thing > (except I have never used them ;) > > thanks > stefan > > Am 11.01.12 19:37, schrieb Benjamin Gudehus: > > I will then commit this into trunk. > > > > 2012

Re: [JPP-Devel] General refactoring of OpenJUMP

sorry for the late reply. Yes I think its fine to commit this - unit tests are a good thing (except I have never used them ;) thanks stefan Am 11.01.12 19:37, schrieb Benjamin Gudehus: > I will then commit this into trunk. > > 2012/1/11 Benjamin Gudehus > > >

Re: [JPP-Devel] General refactoring of OpenJUMP

I will then commit this into trunk. 2012/1/11 Benjamin Gudehus > in this case it is up to you whether to branch or not. as it is an >> addition it will be easy to merge later, it's merely an organizational >> decision. >> >> regards ede > > > here are my steps: > > 0. create eclipse project (mvn

Re: [JPP-Devel] General refactoring of OpenJUMP

> > in this case it is up to you whether to branch or not. as it is an > addition it will be easy to merge later, it's merely an organizational > decision. > > regards ede here are my steps: 0. create eclipse project (mvn eclipse:eclipse failed, so I created it via eclipse, only add libs in /lib

Re: [JPP-Devel] General refactoring of OpenJUMP

> > It must make use and adoption simple, not more complex ! +1 2012/1/11 > the trunk is very reliable these days. i want to keep it that way. > > can you explain what has to be refactored to what degree? changes to core > are especially delicate because we can easily break compatibility with

Re: [JPP-Devel] General refactoring of OpenJUMP

On 11.01.2012 18:20, Benjamin Gudehus wrote: > until now i understood the testing framework as an addition, isn't it? > > > The testing framework is just an additional package, yes. In order to run and > write tests on/for the plugins in the tools menu we don't need any > refactorings. >

Re: [JPP-Devel] General refactoring of OpenJUMP

On 10.01.2012 23:46, Michaël Michaud wrote: >> If we want to directly commit this to trunk without creating a branch, >> I first need to thunk about possible consequences when we refactor exising >> code. >> Stefan maybe has also some ideas about that. > Right, wait for Stefan's and Ede's advice.

Re: [JPP-Devel] General refactoring of OpenJUMP

Hi, If we want to directly commit this to trunk without creating a branch, I first need to thunk about possible consequences when we refactor exising code. Stefan maybe has also some ideas about that. Right, wait for Stefan's and Ede's advice. It must make use and adoption simple, not more com

Re: [JPP-Devel] General refactoring of OpenJUMP

If we want to directly commit this to trunk without creating a branch, I first need to thunk about possible consequences when we refactor exising code. Stefan maybe has also some ideas about that. 2012/1/10 Benjamin Gudehus > Wouldn't be enough to add a new package to the source trunk for >> dev

Re: [JPP-Devel] General refactoring of OpenJUMP

> > Wouldn't be enough to add a new package to the source trunk for > developpers and to exclude the package for releases, and nightly builds ? > > Michaël > Okay. I will relayout the existing source code to fit into the structure of core/trunk. After that I will create a new branch at svn with t

Re: [JPP-Devel] General refactoring of OpenJUMP

Hi, Yes, Stefan already added me to the developers list: https://sourceforge.net/project/memberlist.php?group_id=118054 Fine, The question is now, how to add the framework to the repository. Adding it to the svn would be of course the best way to work together. Sure, I might create a new bran

Re: [JPP-Devel] General refactoring of OpenJUMP

@Michaël > Nice to see your progress on a unit test framework setting. > > It would be good if it could help making a better separation between > plugin parameters and ui stuff. > I think the other plugins should be refactored like you already refactored the UnionByAttributePlugIn. TestToolsTest

Re: [JPP-Devel] General refactoring of OpenJUMP

Hi Benjamin, I've started to build the testing environment a week ago. Let's make a brief summary about what happend since my last post. Documentation was added to the classes and Javadocs and testing results can be generated as html files. Also all needed methods for the tests where arranged

Re: [JPP-Devel] General refactoring of OpenJUMP

Hi! I've started to build the testing environment a week ago. Let's make a brief summary about what happend since my last post. Documentation was added to the classes and Javadocs and testing results can be generated as html files. Also all needed methods for the tests where arranged in TestTools

Re: [JPP-Devel] General refactoring of OpenJUMP

@Stephan Yes, and there is much work to be done :) I'll document that code that we already have. To make it more easier to start with unit testing. @Michael Yes, I think the new testing environment and the upcoming refactorings should go into a svn branch. Scripting/macros: That's how I develo

Re: [JPP-Devel] General refactoring of OpenJUMP

Hi Benjamin, It will take me some times to read carefully your proposals and test your contributions. I see many good ideas. We have just to be careful because we are a small team with limited experience, and OJ is quite a big project with a long history and much legacy code hosted by the pr

Re: [JPP-Devel] General refactoring of OpenJUMP

Hei Benjamin, thanks for your work. Its good that someone steps forwards with introducing unit tests (finally). Give us some time to read & check things out. stefan Am 04.01.12 23:25, schrieb Benjamin Gudehus: > Sorry, the last post became badly formatted, so I post it again. Hope > this looks

Re: [JPP-Devel] General refactoring of OpenJUMP

Sorry, the last post became badly formatted, so I post it again. Hope this looks better. Here is an update: I've finished point 2. Now it's possible to run unittests for the UnionByAttributePlugIn. Project page: https://github.com/hastebrot/openjump-tools-sandbox Zip file: https://github.com/has

Re: [JPP-Devel] General refactoring of OpenJUMP

Here is an update: I've finished point 2. Now it's possible to run unittests for theUnionByAttributePlugIn. Project page: https://github.com/hastebrot/openjump-tools-sandboxZip file: https://github.com/hastebrot/openjump-tools-sandbox/zipball/master Please grab the zip file and try it out. I've inc

Re: [JPP-Devel] General refactoring of OpenJUMP

2. Legacy code and testing How to test plugins (from the tools menu)? (1) Create and setup a JUMPWorkbench with WorkbenchFrame and WorkbenchContext. The method JUMPWorkbench.main() has all needed instructions. In order to run the plugins we need to set WorkbenchFrame visible. This is only require

Re: [JPP-Devel] General refactoring of OpenJUMP

On 03.01.2012 12:50, Benjamin Gudehus wrote: > @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 > FeatureIns

Re: [JPP-Devel] General refactoring of OpenJUMP

@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

Re: [JPP-Devel] General refactoring of OpenJUMP

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 ca

Re: [JPP-Devel] General refactoring of OpenJUMP

Hi Benjamin, yup - what Ede describes is what I do too in Eclipse. I have a OpenJUMP project that I setup and run without any addons (but using the default-plugins option) Then I have setup another Project that will contain my own code. As you describe the PlugIn or is Extension class is where I

Re: [JPP-Devel] General refactoring of OpenJUMP

On 02.01.2012 23:49, Michaël Michaud wrote: > Hi Benjain and happy new year > >> 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

Re: [JPP-Devel] General refactoring of OpenJUMP

Hi Benjain and happy new year 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