I think there are more dependencies on Eclipse. For example SWTBot is no
library (like log4j, junit etc.) but a set of Eclipse plugins.
Concerning patches for making it compatible with Eclipse 3.2: This could be
hard stuff. For example when you are using 3.3 classes from Eclipse, there
would be compile errors on 3.2. But the biggest difficulty would be to backport
the SWTBot test launcher plugin since there has been refactored a lot there and
it requires writing Eclipse plugin knowledge, which I don't have.
Do you know the commercial tools which can also test SWT/RCP, like Froglogic
Squish and QFTest? Its hard to believe that they can only test it if the RCP is
written for Eclipse X.X or higher. They must be compatible with at least
Eclipse 3.x I think. Otherwise it would make no sense for the customers or for
the companies, since they would have to maintain its tool for a variety of
Eclipse/RCP versions. Bottom line is, that I think that they have an
intelligent solution for the compatibility problem. No spine shivers, but
solutions. Maybe its another solution, but there must be soltions others than
patching SWTBot I believe.
I asked in the Sun forum about a solution, they provided some. At least one
will work good I think. I will check that.
By the way, does your team test RCP applications with SWTBot?
--- On Wed, 7/16/08, Ketan Padegaonkar <[EMAIL PROTECTED]> wrote:
From: Ketan Padegaonkar <[EMAIL PROTECTED]>
Subject: Re: [SWTBot-users] Important compatibility issue, mostly RCP related
To: swtbot-users@lists.sourceforge.net
Date: Wednesday, July 16, 2008, 2:48 PM
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
-------------------------------------------------------------------------
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
