On 16-Jul-08, at 10:51 PM, Hans Schwaebli wrote: > Hi Kendar, I need your help. I need you to see me now as a customer, > not as a technician. ;-)
Hmm... lets see... How much money do you have ;) > I can automate the test with SWTBot, even though the versions are > different. How? By copying 3.2. and 3.3 plugins into the same > Eclipse folder. Then the RCP application runs, which we want to > test, and SWTBot runs over it because it has its plugins (both 3.2 > and 3.3). > > But this has a side effect. Our RCP plugins then used 3.3 plugins > instead 3.2 plugins because they were both in the same directory. > For example org.eclipse.ui_3.2.1.M20061108.jar and > org.eclipse.ui_3.3.1.M20071128-0800.jar The only dependency that SWTBot has on eclipse is the launcher -- that's probably the biggest hurdle that I see so far. The workarounds that you mention do sound scary! > One solution could be to run SWTBot "standalone" or isolated in its > classpath requirement, and the RCP or SWT application standalone and > isolated too. > > Two VMs would be involved: one for the JUnit tests with SWTBot and > one for the RCP or SWT application which needs to be tested. It then > would be no PDE JUnit test but a simple JUnit test by the way. > > The RCP/SWT client could be started from the JUnit tests > (Runtime.exec(...) or whatever). Currently SWTBot would not find the > display this way, since it only searches in its own VM. If SWTBot > can find the display in another VM, the compatibility problem - > which I mentioned above - could be solved I think. And it would be > easier to automate running RCP tests from Ant or Maven since it > would be a simple JUnit test (and no PDE Plugin JUnit test). > > Thats the idea. How to solve it? I asked how to get the threads from > another VM in the Sun forum. They provided some solutions, which I > need to verify: http://forum.java.sun.com/thread.jspa?threadID=5313584 Talking stuff across VMs is a *very* hard problem to solve, it sends shivers down my spine and that's not in the scope of SWTBot. > I think SWTBot could benefit by solving this compatibility issue. I > would be very intrested what you think about this idea and about > increasing compatibility. I do agree with all that you say in this email. Unfortunately for me, most of the features on SWTBot is driven from what the team at work, and some from the mailing list and bugzilla. We're currently working with Eclipse 3.3 and support for 3.2 is not _my_ goal. That said, I do agree that this would mean a lot of pain for users using eclipse 3.2 and older, but there's very little that I can do about this. Eclipse 3.2 is very old, and hard for me to support. If you are indeed using eclipse 3.2 for your work, I'd encourage you to file patches when things do not work with 3.2. I do not see any other way to backport SWTBot to 3.2. -- Ketan ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ SWTBot-users mailing list SWTBot-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/swtbot-users http://swtbot.org/ - a functional testing tool for SWT/Eclipse
