akhikhl
Support testing inside running Eclipse
Some parts of plugins/RCP apps can be tested using unit test but other tests will need to run in an initialized Eclipse instance. So far the support for testing with these tests is missing in Wuff and IMO this is a blocker for the adoption.
Some of the ideas how to implement this:
- Allow to add new sourceSet to plugin projects like eclipseTest (in addition to main & test). This would be built into another fragment or plugin. Add a target that will install the original plugin and testing plugin/fragment into a clean Eclipse RCP app/Eclipse IDE. Then launch PDE test listener and this app and let it run PDE test. It should be possible to do it like for the Ant/PDE integration described in http://www.eclipse.org/articles/article.php?file=Article-PDEJUnitAntAutomation/index.html
- Expect project structure like :myPlugin, :myPluginTest. First project builds plugin, second builds its test plugin/fragment. 2nd project also adds a target to run this test similarly as in (1.)
While the (1.) is more Gradle-like the (2.) can be simpler to implement and probably easier to map to Eclipse setups if anyone wants to run these tests directly from Eclipse.
Note that these are my ideas based on my experience with Eclipse 5 years ago. Feel free to use another approach if it is a better way. Meanwhile I will likely try to implement support using on of these approaches.
FYI: here is my work in progress - https://github.com/radimk/PDETestExampleProjectsWithGradle Currently I can run tests in Eclipse and receive results in Gradle. Next step is to process those results like regular JUnit/TestNG test. Probably I will try to modify it to run this code from a Test task.
Open issue: Should we expect there will be one project to setup testing IDE/RCP app and testing plugins/fragments will refer to it? Or should we add wuff-eclipseTest plugin that will add tasks to build installation, prepareRunConfig and integTest to a project? The latter can be simple.
Hi, It's a nice feature, many people will enjoy it. Regarding preferrable approach: I think it is better to stick with Gradle metaphors for testing. I mean, we should implement test task (or integrationTest task), which is facilitated with eclipse/wuff launcher. Multiplying eclipse bundles just for the sake of testing is no good. I'll have a look at your examples over the weekend.
My sample project is improved now to use Test task and report passed/failed tests. Probably not perfect yet but a good start.
Re multiplying bundles: having one project with eclipse-ide-bundle plugin applied (to build plugin from main sourceSet) and eclipse-ide-test-bundle(?) plugin applied (to build testing plugin/fragment from eclipseTest sourceSet) and eclipse-ide-app plugin applied (to build testing Eclipse instance needed to run these test) seems possible but probably not very convenient if you want to import this project into Eclipse and run the plugin or test itself.
I'd suggest to create one Gradle project for the developed bundle and 2nd for the test plugin/fragment. The second project should apply both eclipse-ide-bundle to assemble the bundle and eclipse-ide-app to create test installation. This is not possible at the moment as both plugins try to create createExtraFiles task. Can we fix that? It would make things simpler here.
Thank you for your efforts. Right now I am focusing myself on two vital features in Wuff: eclipse-feature support and p2 repository support. As soon as these features are implemented, I can look more closely at your work.
Sure. I can get it working using setup as you see and wait until we find a way how to add it to wuff. Of course I'll appreciate features/P2 support too :-) BTW: would it make sense to set up a mailing list to discuss the plugin usage and suggestions?
I cloned, compiled and run PDETestExampleProjectsWithGradle. Wow, it works and it looks nice!
Regarding separation to "main" bundle and "test" bundle - I understand, our problem is that OSGi runtime requires everything to be a bundle. And we don't want test code to be in the main bundle, right? What about the following: let's teach Wuff how to produce two bundles: main and test, from multiple source sets? We can even retain compatibility with Eclipse IDE - "build.properties" supports source.<library>, output.<library> syntax for this.
Mailing list - that's a nice idea. I will see to organizing it, maybe over the weekend.
I added some patches: list of test classes needs to be passed as set of arguments instead of one comma-separated expression.
IMO multiple OSGi bundles in one Gradle project is going to be a problem for Eclipse & its PDE. I am still wondering how to set up Eclipse to work with a project that contains just one bundle/plug-in. What I'm looking for is a set up to build a set of IDE plugins (+feature+update site+P2 repo later) with official build managed by Gradle and I want to be able to develop the code using Eclipse to get at least some benefit of its PDE support (and alternatively be able to use other IDEs like IntelliJ).
At the moment
- Eclipse will generate errors if my bundle doesn't contain Bundle-Version: (I wanted to generate it from Gradle build)
- It won't be happy with partial plugin.xml too.
I think this can be partly fixed by adding a build hook to copy the MANIFEST.MF and plugin.xml into special place under build directory and point Eclipse's PDE there using BUNDLE_ROOT_PATH property in .settings/org.eclipse.pde.core.prefs (see lengthy bug report https://bugs.eclipse.org/bugs/show_bug.cgi?id=153023).
Another problem for me is how to bundle a JAR into my plugin and have a set up that works with Gradle and in Eclipse both. I can add a JAR from gradle cache to project classpath (and use Eclipse's classpath variables) but PDE won't include it into bundle when launching from Eclipse. It needs to be in the project. Using linked resources (file or folders) doesn't work with PDE either. So perhaps I'd need to extend the hook mentioned above to cover this library too. Or it can be better to wrap such a library into OSGi bundle itself.
That's my motivation to keep these eclipse tests in their own project until I find a way how to have Eclipse PDE friendly setup.
Yes, you are right. Seamless integration with Eclipse IDE should be a top priority, otherwise acceptance of proposed test feature will be low. But, on the other hand, doubling the number of eclipse bundles... Let's continue thinking on it.
Question: how do you envision the workflow with Wuff Test feature in Eclipse IDE? I mean, should we assume, that users regularly invoke gradle "test" task (via gradle-eclipse integration) or would they invoke tests in some other, more "natural" way?
Invoking one of the Gradle project tasks is one way. The other one is to use 'Run as Plug-in Test' launch type. This one assume that the testing project is PDE compatible.
Understood and agreed. Gradle task and PDE integration - probably we need both? Wuff initially was thought as a build-tool loosely coupled with Eclipse IDE, so that all things could be done in CI.
I have an idea that Wuff should change the way it deals with MANIFEST.MF, plugin.xml and build.properties. Currently it auto-generates or merges (with user-defined versions) these files. The auto-generated and merged versions are not visible to PDE (they reside in buildDir) - now this seems a deficiency to me. What about the following: user-defined versions of the files will be moved to src/main/resources, Wuff will auto-generate and merge to "normal" locations - project root and META-INF? Do you think, it will allow us to make PDE understand Wuff tests?
Seems like a way. It is worth to try this. An alternative it to generate those files into something like build/eclipse-bundle-root and expect that Eclipse project will set BUNDLE_ROOT_PATH property in .settings/org.eclipse.pde.core.prefs. Or better yet just eclipse-bundle-root since you may want to add some extras into this folder (symlinks to other bundled files because PDE does not work with Eclipse linked resources). It can be actually customizable. But you can start with project root if it makes it easier.
Is there some special API in Eclipse to operate on symlinks? Or do you mean java NIO?
Eclipse will handle symlinked files as regular files AFAIK. They created their own linked resources to overcome Windows limitation - http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Ftasks%2Ftasks-45.htm - but it is of no help for us. Neither Gradle doesn't know about them nor PDE.
It's a great work that @radimk done here. Yes, there is question on how to integrate in eclipse while devlopment. But the work is (almost) done to have a 'grade test' (or integrationTest) which work on CLI. And it's already a really nice feature that wuff users could have since almost a year now.
So why not 'merging' @radimk's work now ? (and see what to for 'in eclipse' integration later)
