Re: [JPP-Devel] General refactoring of OpenJUMP
Hi Landon! 2012/1/22 Landon Blake sunburned.surve...@gmail.com 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. No, I didn't mock WorkbenchContext. TestTools.buildWorkbench() uses some methods from JUMPWorkbench.main() to create the Workbench with WorkbenchContext and WorkbenchFrame. I looked at the code here: http://openjump-tools-docs.googlecode.com/git/javadoc/index.html I must admit I'm a little confused. Are you writing an OJ specific unit testing framework from scratch. I didn't see any references to JUnit or another unit testing framework in your code. Since JUnit 4 you may add annotations to Plain Old Java Objects/Classes (POJOs). I use annotations like @Test and @Setup in the test classes. Keep up the good work Benjamin. I wish I had more time to keep up with what you were doing. Thanks. Landon P.S- I really appreciate the tips about running OJ from Eclipse and having it load an extension defined in another Eclipse Project. I'll have to mess around with that, but I may be back to ask for help on getting the Eclipse runtime configuration file set up so I can do this. --Benjamin -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
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 hasteb...@googlemail.com wrote: Hi Landon! 2012/1/22 Landon Blake sunburned.surve...@gmail.com 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. No, I didn't mock WorkbenchContext. TestTools.buildWorkbench() uses some methods from JUMPWorkbench.main() to create the Workbench with WorkbenchContext and WorkbenchFrame. I looked at the code here: http://openjump-tools-docs.googlecode.com/git/javadoc/index.html I must admit I'm a little confused. Are you writing an OJ specific unit testing framework from scratch. I didn't see any references to JUnit or another unit testing framework in your code. Since JUnit 4 you may add annotations to Plain Old Java Objects/Classes (POJOs). I use annotations like @Test and @Setup in the test classes. Keep up the good work Benjamin. I wish I had more time to keep up with what you were doing. Thanks. Landon P.S- I really appreciate the tips about running OJ from Eclipse and having it load an extension defined in another Eclipse Project. I'll have to mess around with that, but I may be back to ask for help on getting the Eclipse runtime configuration file set up so I can do this. --Benjamin -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
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 sunburned.surve...@gmail.com 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 hasteb...@googlemail.com wrote: Hi Landon! 2012/1/22 Landon Blake sunburned.surve...@gmail.com 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. No, I didn't mock WorkbenchContext. TestTools.buildWorkbench() uses some methods from JUMPWorkbench.main() to create the Workbench with WorkbenchContext and WorkbenchFrame. I looked at the code here: http://openjump-tools-docs.googlecode.com/git/javadoc/index.html I must admit I'm a little confused. Are you writing an OJ specific unit testing framework from scratch. I didn't see any references to JUnit or another unit testing framework in your code. Since JUnit 4 you may add annotations to Plain Old Java Objects/Classes (POJOs). I use annotations like @Test and @Setup in the test classes. Keep up the good work Benjamin. I wish I had more time to keep up with what you were doing. Thanks. Landon P.S- I really appreciate the tips about running OJ from Eclipse and having it load an extension defined in another Eclipse Project. I'll have to mess around with that, but I may be back to ask for help on getting the Eclipse runtime configuration file set up so I can do this. --Benjamin -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
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 tests within Eclipse. That made my developement cycle (edit-compile-run/test/debug loop) much shorter. 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. I looked at the code here: http://openjump-tools-docs.googlecode.com/git/javadoc/index.html I must admit I'm a little confused. Are you writing an OJ specific unit testing framework from scratch. I didn't see any references to JUnit or another unit testing framework in your code. Keep up the good work Benjamin. I wish I had more time to keep up with what you were doing. Thanks. Landon P.S- I really appreciate the tips about running OJ from Eclipse and having it load an extension defined in another Eclipse Project. I'll have to mess around with that, but I may be back to ask for help on getting the Eclipse runtime configuration file set up so I can do this. On Fri, Jan 13, 2012 at 3:48 AM, edgar.sol...@web.de wrote: 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 sst...@geo.uzh.ch mailto:sst...@geo.uzh.ch 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 hasteb...@googlemail.com mailto:hasteb...@googlemail.com mailto:hasteb...@googlemail.com mailto:hasteb...@googlemail.com 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) (will not be committed to svn) 1. run all unittests in jumptest/junit (4 errors, 3 failures) 2. remove file core/trunk/lib/junit.jar 3. add file core/trunk/lib/junit.jar (version 4.10) 4. run all unittests in jumptest/junit (4 errors, 3 failures) (sourcecode in core/trunk/src/jumptest builds without errors (I didn't thought junit4 is compatible with junit3).) 5. add files core/trunk/src/org/openjump/test/*.java 6. add files core/trunk/src/fixtures/*.jml 7. run all unittests in core/trunk/src/org/openjump/test (0 errors, 0 failures) 8. run ant -f etc/build.xml (build successful) 9. run openjump (works) 10. modify pom.xml and update junit from 3.8 to 4.10 11. run mvn package -P release(build success) 12. run openjump (works) If everyone is fine with my changes I will commit them. $ svn status A src\org\openjump\test A src\org\openjump\test\TestTools.java A src\org\openjump\test\TestToolsTest.java A src\org\openjump\test\DialogParameters.java A src\org\openjump\test\DialogParametersTest.java A src\org\openjump\test\package-info.java A src\org\openjump\test\ReflectionUtils.java A src\org\openjump\test\ReflectionUtilsTest.java A src\fixtures A src\fixtures\dissolve.jml A src\fixtures\inner-ring.jml A src\fixtures\inner-ring-invalid.jml M pom.xml M lib\junit.jar --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 mailto:Jump-pilot-devel@lists.sourceforge.net
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 hasteb...@googlemail.com mailto:hasteb...@googlemail.com 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) (will not be committed to svn) 1. run all unittests in jumptest/junit (4 errors, 3 failures) 2. remove file core/trunk/lib/junit.jar 3. add file core/trunk/lib/junit.jar (version 4.10) 4. run all unittests in jumptest/junit (4 errors, 3 failures) (sourcecode in core/trunk/src/jumptest builds without errors (I didn't thought junit4 is compatible with junit3).) 5. add files core/trunk/src/org/openjump/test/*.java 6. add files core/trunk/src/fixtures/*.jml 7. run all unittests in core/trunk/src/org/openjump/test (0 errors, 0 failures) 8. run ant -f etc/build.xml (build successful) 9. run openjump (works) 10. modify pom.xml and update junit from 3.8 to 4.10 11. run mvn package -P release(build success) 12. run openjump (works) If everyone is fine with my changes I will commit them. $ svn status A src\org\openjump\test A src\org\openjump\test\TestTools.java A src\org\openjump\test\TestToolsTest.java A src\org\openjump\test\DialogParameters.java A src\org\openjump\test\DialogParametersTest.java A src\org\openjump\test\package-info.java A src\org\openjump\test\ReflectionUtils.java A src\org\openjump\test\ReflectionUtilsTest.java A src\fixtures A src\fixtures\dissolve.jml A src\fixtures\inner-ring.jml A src\fixtures\inner-ring-invalid.jml M pom.xml M lib\junit.jar --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 -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
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 sst...@geo.uzh.ch mailto:sst...@geo.uzh.ch 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 hasteb...@googlemail.com mailto:hasteb...@googlemail.com mailto:hasteb...@googlemail.com mailto:hasteb...@googlemail.com 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) (will not be committed to svn) 1. run all unittests in jumptest/junit (4 errors, 3 failures) 2. remove file core/trunk/lib/junit.jar 3. add file core/trunk/lib/junit.jar (version 4.10) 4. run all unittests in jumptest/junit (4 errors, 3 failures) (sourcecode in core/trunk/src/jumptest builds without errors (I didn't thought junit4 is compatible with junit3).) 5. add files core/trunk/src/org/openjump/test/*.java 6. add files core/trunk/src/fixtures/*.jml 7. run all unittests in core/trunk/src/org/openjump/test (0 errors, 0 failures) 8. run ant -f etc/build.xml (build successful) 9. run openjump (works) 10. modify pom.xml and update junit from 3.8 to 4.10 11. run mvn package -P release(build success) 12. run openjump (works) If everyone is fine with my changes I will commit them. $ svn status A src\org\openjump\test A src\org\openjump\test\TestTools.java A src\org\openjump\test\TestToolsTest.java A src\org\openjump\test\DialogParameters.java A src\org\openjump\test\DialogParametersTest.java A src\org\openjump\test\package-info.java A src\org\openjump\test\ReflectionUtils.java A src\org\openjump\test\ReflectionUtilsTest.java A src\fixtures A src\fixtures\dissolve.jml A src\fixtures\inner-ring.jml A src\fixtures\inner-ring-invalid.jml M pom.xml M lib\junit.jar --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 mailto:Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net mailto:Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
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. It must make use and adoption simple, not more complex ! 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 plugins around. until now i understood the testing framework as an addition, isn't it? ..ede -- 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
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. 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 -- 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
Re: [JPP-Devel] General refactoring of OpenJUMP
It must make use and adoption simple, not more complex ! +1 2012/1/11 edgar.sol...@web.de 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 plugins around. I would start Top-down. First write tests for the components with the least dependencies (i.e. PlugIns in the tools menu). Then refactor the hell out of the Plugins (it won't break anything, because there are no dependencies). If we evolved some best practices for the stucture of these plugins, we could look into more dependent components and think about what is worth refactoring and what could possibly break compatibility. So there is no need to change the core right now. 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. --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
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) (will not be committed to svn) 1. run all unittests in jumptest/junit (4 errors, 3 failures) 2. remove file core/trunk/lib/junit.jar 3. add file core/trunk/lib/junit.jar (version 4.10) 4. run all unittests in jumptest/junit (4 errors, 3 failures) (sourcecode in core/trunk/src/jumptest builds without errors (I didn't thought junit4 is compatible with junit3).) 5. add files core/trunk/src/org/openjump/test/*.java 6. add files core/trunk/src/fixtures/*.jml 7. run all unittests in core/trunk/src/org/openjump/test (0 errors, 0 failures) 8. run ant -f etc/build.xml (build successful) 9. run openjump (works) 10. modify pom.xml and update junit from 3.8 to 4.10 11. run mvn package -P release (build success) 12. run openjump (works) If everyone is fine with my changes I will commit them. $ svn status A src\org\openjump\test A src\org\openjump\test\TestTools.java A src\org\openjump\test\TestToolsTest.java A src\org\openjump\test\DialogParameters.java A src\org\openjump\test\DialogParametersTest.java A src\org\openjump\test\package-info.java A src\org\openjump\test\ReflectionUtils.java A src\org\openjump\test\ReflectionUtilsTest.java A src\fixtures A src\fixtures\dissolve.jml A src\fixtures\inner-ring.jml A src\fixtures\inner-ring-invalid.jml M pom.xml M lib\junit.jar --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
Re: [JPP-Devel] General refactoring of OpenJUMP
I will then commit this into trunk. 2012/1/11 Benjamin Gudehus hasteb...@googlemail.com 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) (will not be committed to svn) 1. run all unittests in jumptest/junit (4 errors, 3 failures) 2. remove file core/trunk/lib/junit.jar 3. add file core/trunk/lib/junit.jar (version 4.10) 4. run all unittests in jumptest/junit (4 errors, 3 failures) (sourcecode in core/trunk/src/jumptest builds without errors (I didn't thought junit4 is compatible with junit3).) 5. add files core/trunk/src/org/openjump/test/*.java 6. add files core/trunk/src/fixtures/*.jml 7. run all unittests in core/trunk/src/org/openjump/test (0 errors, 0 failures) 8. run ant -f etc/build.xml (build successful) 9. run openjump (works) 10. modify pom.xml and update junit from 3.8 to 4.10 11. run mvn package -P release (build success) 12. run openjump (works) If everyone is fine with my changes I will commit them. $ svn status A src\org\openjump\test A src\org\openjump\test\TestTools.java A src\org\openjump\test\TestToolsTest.java A src\org\openjump\test\DialogParameters.java A src\org\openjump\test\DialogParametersTest.java A src\org\openjump\test\package-info.java A src\org\openjump\test\ReflectionUtils.java A src\org\openjump\test\ReflectionUtilsTest.java A src\fixtures A src\fixtures\dissolve.jml A src\fixtures\inner-ring.jml A src\fixtures\inner-ring-invalid.jml M pom.xml M lib\junit.jar --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
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 in TestTools (buildWorkbench, configurePlugIn, executePlugIn). The mechanics on how to provide configuration values and on how to execute the plugin stayed the same. http://openjump-tools-docs.googlecode.com/git/javadoc/index.html http://openjump-tools-docs.googlecode.com/git/testdoc/report/index.html http://openjump-tools-docs.googlecode.com/git/checkstyle/report/report.html I've also documented/outlined two different types of testable plugins (see also Javadocs for documentation): 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. Have you commit rights on the project's svn ? Michaël ExamplePlugInWithFields: http://goo.gl/sjHUs ExamplePlugInWithDialog: http://goo.gl/KWN06 If something is unclear I could improve the code/comments. It looks very promising so far; next up is implementing test cases for UnionByAttributePlugIn. Repository: https://github.com/hastebrot/openjump-tools-sandbox/ Zipped Eclipse Project: https://github.com/hastebrot/openjump-tools-sandbox/zipball/master Greetings Benjamin -- 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
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.ExamplePlugInWithFields is how it works with the refactored version and TestToolsTest.ExamplePlugInWithDialog is how it works with the old versoin of UnionByAttributePlugIn. Have you commit rights on the project's svn ? Yes, Stefan already added me to the developers list: https://sourceforge.net/project/memberlist.php?group_id=118054 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. I might create a new branch and add the sourcecode as a new project somewhere. Before that I would change the dependencies from the test/lib directory to the core/lib directory and add core as a project dependency to eclipse. --Benjamin -- 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
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 branch and add the sourcecode as a new project somewhere. Before that I would change the dependencies from the test/lib directory to the core/lib directory and add core as a project dependency to eclipse. 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 --Benjamin -- 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
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 the integrated test environment. What are the right commands to create this branch in svn? I last used svn in 2006 or so (I usually use distributed VCS like mercurial and git). --BEnjamin -- 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
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 hasteb...@googlemail.com 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 the integrated test environment. What are the right commands to create this branch in svn? I last used svn in 2006 or so (I usually use distributed VCS like mercurial and git). --BEnjamin -- 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
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 complex ! Michaël 2012/1/10 Benjamin Gudehus hasteb...@googlemail.com mailto:hasteb...@googlemail.com 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 the integrated test environment. What are the right commands to create this branch in svn? I last used svn in 2006 or so (I usually use distributed VCS like mercurial and git). --BEnjamin -- 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
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 required because
WorkbenchFrame.position() wants to relocate internal frames, but
shouldn't be a requirement. However to show the WorkbenchFrame could
be helpful when developing test cases.
(2) Initialize and call (execute and/or run) PlugIns. The method
AbstractPlugIn.toActionListener() has all needed instructions. We need
to wait until the plugin finished until assertions can be made. We
should test plugins with different dialog values handled to the plugin
and all private methods directly.
I finished point (1) and am working in point (2). After that I will
but some source code online, so everyone can experiment a bit with
tests.
-
Now let's look at (A) the structure of the source code of an example
plugin and then (B) formulate the layout of a test class. After that
we can (C) formulate a guideline to refactor existing legacy plugins.
Concerning (A): I'll use UnionByAttributePlugIn (sourcecode: [1]) as a
showcase and later as a object-under-test. Michaël recently made some
nice refactorings (sourcecode: [2]) on this plugin that also improved
cohesion on the source code. I think [1] has the following structure:
[1] https://gist.github.com/1554708#file_union_by_attribute_plug_in.java
[2] https://gist.github.com/1554708#file_union_by_attribute_plug_in.r2519.java
1. PlugIn installation (JUMPWorkbench/Setup)
- Constructor (empty)
public UnionByAttributePlugIn() {}
- Method: initialize() / FeatureInstaller
2. Input dialog (PlugIn.execute())
- Fields: Translation Strings
private final static String LAYER = I18N.get(...PlugIn.layer);
- Field: Dialog
private MultiInputDialog dialog;
- Method: initDialog()
- Method: execute() to initialize and show the dialog
3. Execution/Result/Report (Ok button)
- Method: run() to run the tool asynchronously
privateMethods
It consists of three parts. 1. provides an initialize() method for
JUMPWorkbench/Setup which installs a menu entry. 2. provides a multi
input dialog which provides a key store with different values (I
really like this key/value concept). The dialog is shown to the user
with execute(). 3. is the run() method which creates a result layer
and makes use of private methods.
We should refactor the plugins later, so calling them is possible in
two different ways. Firstly by showing the user a multi input dialog
and secondly by provide key-values directly to the plugins. The
changes by Michaël in [2] resemble exactly what I'm thinking of: He
introduced some field to the plugin class analogue to the fields in
the dialog. For now I'll try to subclass MultiInputDialog for tests to
provide custom values to the plugin, without setting the dialog
visible. Then I'll set it as the private field dialog.
Concerning (B): Layout of a test class
@BeforeClass: Create a WorkbenchFrame (and optionally set it visible).
@Before: Create a new TaskFrame.
@Test: Multible test cases.
- Load a Shapefile.
- Call the PlugIn with arguments.
- do assertions
@After: Close all internal frames (projects)
@AfterClass: Close the WorkbenchFrame
For all tests cases (@Tests) we need a single
WorkbenchFrame/WorkbenchContext which is initialized in @BeforeClass.
A single test case loads a shapefile and calls the plugin with
arguments (my custom MultiInputDialog). Then multiple assertions
follow. After that we will close all internal frames in @After.
I'll write about (C) later.
--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
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 included all
openjumplibraries and added junit4 in the lib directory, so everyone
hasnothing to do but import the project into eclipse.
You may start with executing the junit tests
insrc/org/openjump/tools/tests/TestToolsTest.java. I'm happy about
anysuggestion and feedback. You'll see that the tests work, but
thatthere are some refactorings needed on the OpenJump source code.
You'llalso see that I've tried to write it BDD style
(given-when-then).
This is just a sandbox for concepts. Eventually I will copy thesources
into openjump's subversion repository, when everything wentfine.
Here is what I have to write about (C) formulate a guideline
torefactor existing legacy plugins:
1. Create an empty Java.project for experiments2. Copy jar
depenndecies to lib3. Copy single PlugIn source to src (downside: out
of main repositoryversion control)4. Try to run plugin5. Refactor
PlugIn (maybe) to execute simple test with a shapefilefixture (chance
no behaviour)6. Write Tests for bounded context and edge cases7.
Refactor mercilessly
So we are now at point 6. I've changed nothing
inUnionByAttributePlugIn. Next thing is towrite all tests /
interactions for it.
--Benjamin
2012/1/4 Benjamin Gudehus hasteb...@googlemail.com:
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 required because
WorkbenchFrame.position() wants to relocate internal frames, but
shouldn't be a requirement. However to show the WorkbenchFrame could
be helpful when developing test cases.
(2) Initialize and call (execute and/or run) PlugIns. The method
AbstractPlugIn.toActionListener() has all needed instructions. We need
to wait until the plugin finished until assertions can be made. We
should test plugins with different dialog values handled to the plugin
and all private methods directly.
I finished point (1) and am working in point (2). After that I will
but some source code online, so everyone can experiment a bit with
tests.
-
Now let's look at (A) the structure of the source code of an example
plugin and then (B) formulate the layout of a test class. After that
we can (C) formulate a guideline to refactor existing legacy plugins.
Concerning (A): I'll use UnionByAttributePlugIn (sourcecode: [1]) as a
showcase and later as a object-under-test. Michaël recently made some
nice refactorings (sourcecode: [2]) on this plugin that also improved
cohesion on the source code. I think [1] has the following structure:
[1] https://gist.github.com/1554708#file_union_by_attribute_plug_in.java
[2] https://gist.github.com/1554708#file_union_by_attribute_plug_in.r2519.java
1. PlugIn installation (JUMPWorkbench/Setup)
- Constructor (empty)
public UnionByAttributePlugIn() {}
- Method: initialize() / FeatureInstaller
2. Input dialog (PlugIn.execute())
- Fields: Translation Strings
private final static String LAYER = I18N.get(...PlugIn.layer);
- Field: Dialog
private MultiInputDialog dialog;
- Method: initDialog()
- Method: execute() to initialize and show the dialog
3. Execution/Result/Report (Ok button)
- Method: run() to run the tool asynchronously
privateMethods
It consists of three parts. 1. provides an initialize() method for
JUMPWorkbench/Setup which installs a menu entry. 2. provides a multi
input dialog which provides a key store with different values (I
really like this key/value concept). The dialog is shown to the user
with execute(). 3. is the run() method which creates a result layer
and makes use of private methods.
We should refactor the plugins later, so calling them is possible in
two different ways. Firstly by showing the user a multi input dialog
and secondly by provide key-values directly to the plugins. The
changes by Michaël in [2] resemble exactly what I'm thinking of: He
introduced some field to the plugin class analogue to the fields in
the dialog. For now I'll try to subclass MultiInputDialog for tests to
provide custom values to the plugin, without setting the dialog
visible. Then I'll set it as the private field dialog.
Concerning (B): Layout of a test class
@BeforeClass: Create a WorkbenchFrame (and optionally set it visible).
@Before: Create a new TaskFrame.
@Test: Multible test cases.
- Load a Shapefile.
- Call the PlugIn with arguments.
- do assertions
@After: Close all internal frames (projects)
@AfterClass: Close the WorkbenchFrame
For all tests cases
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 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/hastebrot/openjump-tools-sandbox/zipball/master Please grab the zip file and try it out. I've included all openjump libraries and added junit4 in the lib directory, so everyone has nothing to do but import the project into eclipse. You may start with executing the junit tests in src/org/openjump/tools/tests/TestToolsTest.java. I'm happy about any suggestion and feedback. You'll see that the tests work, but that there are some refactorings needed on the OpenJump source code. You'll also see that I've tried to write it BDD style (given-when-then). This is just a sandbox for concepts. Eventually I will copy the sources into openjump's subversion repository, when everything went fine. Here is what I have to write about (C) formulate a guideline to refactor existing legacy plugins: 1. Create an empty Java.project for experiments 2. Copy jar depenndecies to lib 3. Copy single PlugIn source to src (downside: out of main repository version control) 4. Try to run plugin 5. Refactor PlugIn (maybe) to execute simple test with a shapefile fixture (chance no behaviour) 6. Write Tests for bounded context and edge cases 7. Refactor mercilessly See also: Manuel Küblböck: “How to make changes to rotten legacy code”, http://qualityswdev.com/2011/02/09/how-to-make-changes-to-rotten-legacy-code/ So we are now at point 6. I've changed nothing in UnionByAttributePlugIn. Next thing is to write all tests / interactions for it. --Benjamin 2012/1/4 Benjamin Gudehus hasteb...@googlemail.com mailto:hasteb...@googlemail.com: 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 included all openjumplibraries and added junit4 in the lib directory, so everyone hasnothing to do but import the project into eclipse. You may start with executing the junit tests insrc/org/openjump/tools/tests/TestToolsTest.java. I'm happy about anysuggestion and feedback. You'll see that the tests work, but thatthere are some refactorings needed on the OpenJump source code. You'llalso see that I've tried to write it BDD style (given-when-then). This is just a sandbox for concepts. Eventually I will copy thesources into openjump's subversion repository, when everything wentfine. Here is what I have to write about (C) formulate a guideline torefactor existing legacy plugins: 1. Create an empty Java.project for experiments2. Copy jar depenndecies to lib3. Copy single PlugIn source to src (downside: out of main repositoryversion control)4. Try to run plugin5. Refactor PlugIn (maybe) to execute simple test with a shapefilefixture (chance no behaviour)6. Write Tests for bounded context and edge cases7. Refactor mercilessly So we are now at point 6. I've changed nothing inUnionByAttributePlugIn. Next thing is towrite all tests / interactions for it. --Benjamin 2012/1/4 Benjamin Gudehus hasteb...@googlemail.com mailto:hasteb...@googlemail.com: 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 required because WorkbenchFrame.position() wants to relocate internal frames, but shouldn't be a requirement. However to show the WorkbenchFrame could be helpful when developing test cases. (2) Initialize and call (execute and/or run) PlugIns. The method AbstractPlugIn.toActionListener() has all needed instructions. We need to wait until the plugin finished until assertions can be made. We should test plugins with different dialog values handled to the plugin and all private methods directly. I finished point (1) and am working in point (2). After that I will but some source code online, so everyone can experiment a bit with tests. - Now let's look at (A) the structure of the source code of an example plugin and then (B) formulate the layout of a test class. After that we can (C) formulate a guideline to refactor existing legacy plugins. Concerning (A): I'll use UnionByAttributePlugIn
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 project or by other projects. That said, I don't know how much you can contribute, and what's your vision for OJ. If you have time for important contributions, maybe it's worthwhile creating a branch in the svn, to be able to test more innovative changes while keeping and updating a stable release. Let's see what Stefan and Ede say. Michaël PS : Having a very quick look at your examples, I thought that the required refactoring could help making plugins scriptables (currently, it's quite difficult to use plugins from beanshell), and maybe later to implement a macro recorder (though, I may have extrapolated a bit too far ;o)). Le 04/01/2012 23:25, Benjamin Gudehus a écrit : 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/hastebrot/openjump-tools-sandbox/zipball/master Please grab the zip file and try it out. I've included all openjump libraries and added junit4 in the lib directory, so everyone has nothing to do but import the project into eclipse. You may start with executing the junit tests in src/org/openjump/tools/tests/TestToolsTest.java. I'm happy about any suggestion and feedback. You'll see that the tests work, but that there are some refactorings needed on the OpenJump source code. You'll also see that I've tried to write it BDD style (given-when-then). This is just a sandbox for concepts. Eventually I will copy the sources into openjump's subversion repository, when everything went fine. Here is what I have to write about (C) formulate a guideline to refactor existing legacy plugins: 1. Create an empty Java.project for experiments 2. Copy jar depenndecies to lib 3. Copy single PlugIn source to src (downside: out of main repository version control) 4. Try to run plugin 5. Refactor PlugIn (maybe) to execute simple test with a shapefile fixture (chance no behaviour) 6. Write Tests for bounded context and edge cases 7. Refactor mercilessly See also: Manuel Küblböck: How to make changes to rotten legacy code, http://qualityswdev.com/2011/02/09/how-to-make-changes-to-rotten-legacy-code/ So we are now at point 6. I've changed nothing in UnionByAttributePlugIn. Next thing is to write all tests / interactions for it. --Benjamin 2012/1/4 Benjamin Gudehus hasteb...@googlemail.com mailto:hasteb...@googlemail.com: 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 included all openjumplibraries and added junit4 in the lib directory, so everyone hasnothing to do but import the project into eclipse. You may start with executing the junit tests insrc/org/openjump/tools/tests/TestToolsTest.java. I'm happy about anysuggestion and feedback. You'll see that the tests work, but thatthere are some refactorings needed on the OpenJump source code. You'llalso see that I've tried to write it BDD style (given-when-then). This is just a sandbox for concepts. Eventually I will copy thesources into openjump's subversion repository, when everything wentfine. Here is what I have to write about (C) formulate a guideline torefactor existing legacy plugins: 1. Create an empty Java.project for experiments2. Copy jar depenndecies to lib3. Copy single PlugIn source to src (downside: out of main repositoryversion control)4. Try to run plugin5. Refactor PlugIn (maybe) to execute simple test with a shapefilefixture (chance no behaviour)6. Write Tests for bounded context and edge cases7. Refactor mercilessly So we are now at point 6. I've changed nothing inUnionByAttributePlugIn. Next thing is towrite all tests / interactions for it. --Benjamin 2012/1/4 Benjamin Gudehus hasteb...@googlemail.com mailto:hasteb...@googlemail.com: 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 required because WorkbenchFrame.position() wants to relocate internal frames, but shouldn't be a requirement. However to show the WorkbenchFrame could be helpful when developing test cases. (2) Initialize and call (execute and/or run) PlugIns. The method
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 developed all of my plugins; there is no need to show a dialog. 2012/1/5 Michaël Michaud michael.mich...@free.fr 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 project or by other projects. That said, I don't know how much you can contribute, and what's your vision for OJ. If you have time for important contributions, maybe it's worthwhile creating a branch in the svn, to be able to test more innovative changes while keeping and updating a stable release. Let's see what Stefan and Ede say. Michaël PS : Having a very quick look at your examples, I thought that the required refactoring could help making plugins scriptables (currently, it's quite difficult to use plugins from beanshell), and maybe later to implement a macro recorder (though, I may have extrapolated a bit too far ;o)). Le 04/01/2012 23:25, Benjamin Gudehus a écrit : 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/hastebrot/openjump-tools-sandbox/zipball/master Please grab the zip file and try it out. I've included all openjump libraries and added junit4 in the lib directory, so everyone has nothing to do but import the project into eclipse. You may start with executing the junit tests in src/org/openjump/tools/tests/TestToolsTest.java. I'm happy about any suggestion and feedback. You'll see that the tests work, but that there are some refactorings needed on the OpenJump source code. You'll also see that I've tried to write it BDD style (given-when-then). This is just a sandbox for concepts. Eventually I will copy the sources into openjump's subversion repository, when everything went fine. Here is what I have to write about (C) formulate a guideline to refactor existing legacy plugins: 1. Create an empty Java.project for experiments 2. Copy jar depenndecies to lib 3. Copy single PlugIn source to src (downside: out of main repository version control) 4. Try to run plugin 5. Refactor PlugIn (maybe) to execute simple test with a shapefile fixture (chance no behaviour) 6. Write Tests for bounded context and edge cases 7. Refactor mercilessly See also: Manuel Küblböck: “How to make changes to rotten legacy code”, http://qualityswdev.com/2011/02/09/how-to-make-changes-to-rotten-legacy-code/ So we are now at point 6. I've changed nothing in UnionByAttributePlugIn. Next thing is to write all tests / interactions for it. --Benjamin 2012/1/4 Benjamin Gudehus hasteb...@googlemail.com: 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 included all openjumplibraries and added junit4 in the lib directory, so everyone hasnothing to do but import the project into eclipse. You may start with executing the junit tests insrc/org/openjump/tools/tests/TestToolsTest.java. I'm happy about anysuggestion and feedback. You'll see that the tests work, but thatthere are some refactorings needed on the OpenJump source code. You'llalso see that I've tried to write it BDD style (given-when-then). This is just a sandbox for concepts. Eventually I will copy thesources into openjump's subversion repository, when everything wentfine. Here is what I have to write about (C) formulate a guideline torefactor existing legacy plugins: 1. Create an empty Java.project for experiments2. Copy jar depenndecies to lib3. Copy single PlugIn source to src (downside: out of main repositoryversion control)4. Try to run plugin5. Refactor PlugIn (maybe) to execute simple test with a shapefilefixture (chance no behaviour)6. Write Tests for bounded context and edge cases7. Refactor mercilessly So we are now at point 6. I've changed nothing inUnionByAttributePlugIn. Next thing is towrite all tests / interactions for it. --Benjamin 2012/1/4 Benjamin Gudehus hasteb...@googlemail.com: 2. Legacy code and testing How to test plugins (from the tools menu)? (1) Create and setup a JUMPWorkbench with WorkbenchFrame and WorkbenchContext. The
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 can hook into OJ. Hence, my plugin classes are called using the workbench-properties.xml file that I place in my project - and that is called with the command line option: http://sourceforge.net/apps/mediawiki/jump-pilot/index.php?title=How_to_use_a_plugin_with_a_properties_file_in_ECLIPSE It works like default-plugins. 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. stefan PS: sorry, seems like we really should expose the developer primers better - or write a downloadable manual. Am 03.01.12 00:03, schrieb edgar.sol...@web.de: 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 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. Not that tedious, but it depends on what you are testing. For the UI part (which is quite important in my plugins) this kind of cycle is difficult to avoid. For algorithm part, of course, this is no very efficient, and we miss something like a unit test framework. uhm, don't want to spoil anything, but you don't have to package a jar for development. the intended way to develop extensions with plugins is afaik like this: - set up oj core as an eclipse project, add the libs, see that you can run the workbench class with appropriate arguments - set up a project for your extension - add your extension project to the workbench run configuration classpath - specify a path to a workbench-properties.xml in the run configuration program arguments and add your extension/plugin in the xml file - when you (debug)run this you run oj with the ext/plugin loaded 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 often start my plugins with small beanshell scripts (to understand how jts functions work before starting a plugin for example) I also heard about tools to reload class dynamically without restarting OpenJUMP (Eric, a co-worker, used it for his OpenJUMP plugin, I will ask him) when you run the configuration described above in debug mode you can even do limited hacking and the jre reloads the classes during runtime. -- 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 -- 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
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 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
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 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
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 FeatureInstaller or PlugIn.initialize(), i.e. I initialize my plugins in the Extension. works analogúe, simply add the extension instead of each plugin to the xml file. ..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
[JPP-Devel] General refactoring of OpenJUMP
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
