Re: Jemmy3, SWT and the Robot framework

[Laurent Carbonnaux]

Hi Ricardo,

First, I have change the mailing list to the correct one on eclipselibrary in order not to disturb the core rf developpers!

Then about your problem:

Eclipse Library can manage eclipse RCP application or java applications using SWT widgets.

It seams you need the first solution.

You need then to use eclipsebot.bat and adapt it to your context:

@echo off

set ECLIPSE_LIBRARY=dist/eclipselibrary-0.17-with-dependencies-e36 <== set here your version of the eclipse library jar, should be 0.17 for eclipse 3.6 or for 3.5

set ROBOTFRAMEWORK=libext/robotframework-2.7.7.jar <== the latest RF version

java -Xmx512m -XX:MaxPermSize=256M  -Xbootclasspath/a:%ECLIPSE_LIBRARY% -jar  %ROBOTFRAMEWORK% --debugfile jybot.log --loglevel DEBUG --outputdir results %* 

Then download A_TestEclipseLibrary_installation.html file

open it,

Modify eclipse launching keyword parameters:

${eclipse_install}	file:/D:/eclipse/eclipse-jee-helios-SR2-win32	# -install eclipse parameter to set eclipse installation directory	# where eclipse.exe is
${eclipse_data}	file:/D:/bootstrap36-robot/worskspace_blank	# -data eclipse parameter to set workspace
${eclipse_params}	-consolelog -debug	# other eclipse parameters to set for eclipse startup

then if you launch the following command, it should work:

eclipsebot.bat A_TestEclipseLibrary_installation.html

Let me know if it works.

If not, check if you have installed SWTBot plugin and EclipseLibraryPlugin in your eclipse platform

For GEF, let me check what can be done quickly.

Regards,

Laurent.

2013/5/10 Ricardo de Matos <ricardo....@gmail.com>

Hei Pekka, kiitos vastauksesta.

Bonjour Laurent, je vous remercie pour votre réponse.

As you mentioned, Pekka, the Jemmy documentation doesn't help us develop new libraries upon it and also there isn't the guarantee that it can test GEF components. So we decided to use the SWTBot and, as such, the EclipseLibrary.

We followed the tutorial available on https://code.google.com/p/robotframework-eclipselibrary/wiki/InstallationForEclipse and managed to make the test case work in our machines.

We succeeded in using the eclipsebot.bat and the swtbot.bat approach.

We also succeeded in using the eclipselibrary-x.x-with-dependencies-swt.jar and the standalone version.

What we did not succeeded was to run the test in a new Eclipse installation. 

In this case, the Start Eclipse keyword fails to start Eclipse.

After some banging on the wall, we discovered that we have to first open Eclipse through the eclipse.exe program (or through the command line java -jar eclipse/plugins/org.eclipse.equinox.launcher_1.0.0.v20070606.jar), because this allows the configuration directory (e.g. C:\Program Files\eclipse\Indigo\configuration) to be properly filled with the plugins data.

After this first start-up, the RF test succeeds.

Since the eclipse.exe is just a wrapper for the complete command line to start Eclipse, we tried to feed some of these command line options to the keyword Start Eclipse (e.g. -configuration file:/C:/Program Files/eclipse/Indigo/configuration), but with no luck.

We also tried using the keyword Start Application In Separate Thread and not only it has the same problem described for keyword Start Eclipse, but it also makes the remaining keywords of the test case to fail, because then the widgets can not be referenced.

Another test we made was to use the Start Application keyword.

In this case, Eclipse starts properly, even if it is the first time, but the widgets can not be referenced and so the test also fails.

We looked to the EclipseLibrary keywords source code, but it doesn't reveals a reason for this problems.

- Why starting an Eclipse instance in another thread requires it having the configuration directory filled?

- Why starting an Eclipse instance with the Start Application In Separate Thread keyword does not produces the same result as with keyword Start Eclipse ?

Laurent, can you please help us find the answers for these questions ?

Meanwhile we solved this problem by first starting Eclipse through the SWTBot command line and then we close it with a SWTBot test. 

After this we can use the EclipseLibrary to run our RF tests.

Not an elegant solution, in my opinion...

We are also planning on extending your library to support GEF, since SWTBot 2.1.0 has this functionality and we need it to achieve our goal.

Kiitos / Merci,

Ricardo de Matos
忘れていない

On Fri, May 3, 2013 at 6:37 PM, Laurent Carbonnaux <laurent.c...@gmail.com> wrote:

Hi All,

EclipseLibrary is still alive!

The fact it's seams not is that I didn't provide any new enhancement for a while, because I didn't need for my self use, and really no much time.

I at least give support to people who need help using it.

So if you want more, please ask for or help me develop it.

Regards,

Laurent.

2013/5/3 Pekka Klärck <pe...@iki.fi>

2013/4/22 Ricardo de Matos <ricardo....@gmail.com>:
>
> I'm included in a small team responsible for automate some test cases,
> through the robot framework, for an application developed in SWT.
>
> To accomplish this we have considered the following options:
> - use the eclipse library, which is a bridge for SWTBot
> (https://code.google.com/p/robotframework-eclipselibrary/);
> - use Jemmy3 (https://jemmy.java.net/) as a driver to access the SWT
> components;
>
>
> The eclipse library is no longer developed and it doesn't support testing
> graphs, which is one of the areas we want to automate.
> Plus, it forces us to copy several files to the installation path to
> properly function.

Are you sure the EclipseLibrary isn't developed anymore? I know there
hasn't been releases recently, but that doesn't mean the project is
dead. Have you checked would it be possible to add graph testing
support to it and fix other problems you have encountered? Could be
less work than developing a totally new library.

I added Laurent Carbonnaux, the main developer behind EclipseLibrary
into Cc. Laurent, can you comment what is the status of the library?

> I prefer the option of using Jemmy3 and follow a similar path as the
> SwingLibrary.
>
> The problem here is that this SWTLibrary can not be implemented following
> the SwingLibrary as an example, because Jemmy3 is implement differently from
> Jemmy2, in which the SwingLibrary is constructed upon.

I've understood that Jemmy 3 is pretty much totally different than
Jemmy 2. They cannot apparently even be used for testing same UI
technologies. That's why SwingLibrary is not going to switch the Jemmy
3.

> The documentation is also scarce for Jemmy, making it even harder to start
> building this new library.

Yes, this is big problem with Jemmy, regardless the version.

Cheers,
    .peke
--
Agile Tester/Developer/Consultant :: http://eliga.fi
Lead Developer of Robot Framework :: http://robotframework.org

[Laurent Carbonnaux]

Also,

You don't need to start eclipse separatly.

The StartEclipse keyword do it for you, and it does the same as StartEclipseInSeparateTrhead. Both keywords are there for java library compliance.

About your questions:

- Why starting an Eclipse instance in another thread requires it having the configuration directory filled?

It should not need to have a different configuration, it depends only on the workspace you use. If you launch eclipse in the same workspace as manually, then, you will get your configuration.

- Why starting an Eclipse instance with the Start Application In Separate Thread keyword does not produces the same result as with keyword Start Eclipse ?

You cannot start eclipse with Start Application (or I don't know how), you may use StartEclipse (or StartEclipseInSeparateThread which is the same), see my previous mail for configuration parameters

Hope it helps,

Laurent.

2013/5/13 Laurent Carbonnaux <laurent.c...@gmail.com>

[Laurent Carbonnaux]

Hello Ricardo,

Ok, I understand better what is your problem. I never check this scenario.

I always start Eclipse once first.

I need to get further in this, let me check and come back to you soon.

By this time you can at least keep on testing while starting eclipse once first.

Regards,

Laurent.

2013/5/13 Ricardo de Matos <ricardo....@gmail.com>

Hello Laurent,

Merci pour votre réponse. 

Yes, we are trying to test an Eclipse RCP application. 

We have no problem in following the steps described in the online tutorial or the ones described below for the batch file and the RF test suite.

Please check the attached files, which are the ones we are using (the SWTBot and the EclipseLibrary plugin are both installed in our Eclipse installation).

The problem exists when it's the "first time" you start Eclipse through the RF test suite.

Try this:

- Unzip Eclipse Indigo to a directory of your choice;

- Launch Eclipse and install the SWTBot (http://download.eclipse.org/technology/swtbot/helios/dev-build/update-site) and the EclipseLibrary (http://scrumvision.sourceforge.net/update-site/eclipselibrary) plugins from the update sites indicated in the tutorial;

- Close Eclipse;

- Delete the contents from directory %eclipse_home%\configuration, keeping only the original files (tip: compare it with the eclipse.zip file); --> at this point it's like having installed Eclipse with already the necessary plugins

- Delete the contents of the workspace;

- Launch the RF test case; --> it fails to start Eclipse! 

The log files of this example are in attachment.

Using the keyword Start Application In Separate Thread (you are referring to it as "StartEclipseInSeparateTrhead") produces the same problem and also it fails to reference the widgets.

Merci,

Ricardo de Matos
忘れていない 

[Laurent Carbonnaux]

Hello Ricardo,

I have checked with your scenario. In fact Eclipse itself doesn't launch if you delete configurations file after update.

If you delete "contents from directory %eclipse_home%\configuration", you delete alos last update plugins configuration and OSGI doesn't seam to like it. See attached file log from eclipse.

If you want to install a complete new RCP application with all needed plugins (SWTBot and EclipseLibrary), you need to add them to the deployement descriptor.

Regards,

Laurent.

[Laurent Carbonnaux]

Hello Ricardo,

Nice to write in French! In which language should I answer you? Where are you from?

Yes, I have kept the original files but it fails.

Deployment descriptor is myproduct.product file which may be at the root of your rcp application project folder.

Regards,

Laurent.

2013/5/14 Ricardo de Matos <ricardo....@gmail.com>

Bonjour Laurent,

Did you retained the original files in directory %eclipse_home%\configuration ?

(please see attached print-screen)

Excuse moi, but what is the deployment descriptor file of Eclipse ? 

Can you please point me to documentation about it ?

Merci beaucoup, 

Ricardo de Matos
忘れていない

[Ricardo de Matos]

Bonjour Laurent,

Did you retained the original files in directory %eclipse_home%\configuration ?

(please see attached print-screen)

Excuse moi, but what is the deployment descriptor file of Eclipse ? 

Can you please point me to documentation about it ?

Merci beaucoup, 

Ricardo de Matos
忘れていない

[Ricardo de Matos]

Hi!

I am from Portugal and I had 3 years of French in Middle School (Junior High/Secondary School). 

Nowadays it's a bit rusty... 

If you reply in French, I will understand it, but since we are also replying to the googlegroups, I think it's better to keep it in English... at least in general! 

In Eclipse, or in our product installation directory, the closest I can find to a "myproduct.product" file is the ".eclipseproduct" file, but this doesn't contain any relevant information.

Excuse moi, but I'm new to the context of Eclipse RCP applications programming, so all the help to understand this concept of deployment descriptor is very welcomed. 

Also, I apologize for insisting, but I still have these questions in my mind:

- Why starting an Eclipse instance in another thread requires it having the configuration directory filled ?

  If you use the keyword Start Application, you can start Eclipse, even if it's the "first time".

  If you use the keyword Start Application In Separate Thread, you can not start Eclipse.

  The code for these 2 keywords is the same, with the exception of encapsulating the later in a thread... 

https://code.google.com/p/robotframework-eclipselibrary/source/browse/trunk/org.lcx.robotframework.eclipselibrary/src/org/lcx/robotframework/eclipse/keyword/launch/ApplicationLaunchingKeywords.java

- Why starting an Eclipse instance with the Start Application In Separate Thread keyword does not produces the same result as with keyword Start Eclipse ?

  I'm asking this because it seems to me more correct to write in my RF test "Start Application In Separate Thread com.myCompany.myProductMainClass" than "Start Eclipse". 

  Here the answer is in the code, on the line that says:

  "Change the eclipse escurity manager in order to be able to launch it"

https://code.google.com/p/robotframework-eclipselibrary/source/browse/trunk/org.lcx.robotframework.eclipselibrary/src/org/lcx/robotframework/eclipse/keyword/launch/EclipseLaunchingKeywords.java

   But this leads me to another question:

- Shouldn't the Start Application In Separate Thread keyword have the same code in keyword Start Eclipse ?

   The idea here would be to something like this:

@RobotKeyword("Start Eclipse with the given arguments in a separate thread\n")

@ArgumentNames({"*args"})

public void startEclipse(String[] args) throws SWTBotBridgeException {

// Searching and loading the launcher jar of eclipse in the -install folder     log.debug("loading eclipse launcher jar");     EclipseUtil eu = new EclipseUtil();     try {     eu.loadEclipseLauncherJar(args);     } catch (MalformedURLException e1) {     throw new SWTBotBridgeException(e1);     }         startApplicationInSeparateThread(ECLIPSE_LAUNCHER_CLASS, args);

}

Merci,

Ricardo de Matos
忘れていない

[Laurent Carbonnaux]

Hi Ricardo,

I keep on writing in english since my Portuguese is very bad!

Let me try to answer your questions, one by one:

1/ You need a .product file if you are building an independent RCP application.

If it's a plugin, then only required plugins are to be specified in the manifest file in Dependencies tab. 

2/ For starting Eclipse, the keywords to be used are not "Start Application" but "Start Eclipse"

Then both "Start Eclipse" or "Start Eclipse In Separate Thread" do exactly the same.

see code bellow, it's the same code, startEclipse call startEclipseInSeparateThread

    public void startEclipse(String[] args) throws SWTBotBridgeException {

    startEclipseInSeparateThread(args);

    }

I start Eclipse in a separate thread in order to let the eclipse GUI event thread (and others) running without blocking robotframework one.

3/ then in my platform, it is not working anytime if you get the configuration folder back to unzipped one.

I have a question, is it a real RCP application, or is it a java application using SWT?

If it's a RCP application, you need to start with "Start Eclipse" keyword, "Start Application" may not work properly, it's for java applications, not eclipse ones.

para a próxima

Laurent.

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes robotframework-eclipselibrary-users.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse robotframework-eclipsel...@googlegroups.com.
Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
 
 

[Laurent Carbonnaux]

Hello Ricardo,

I think the mail below hasn't been sent to you

Here it is again.

[Laurent Carbonnaux]

Hi Ricardo,

About Gef support, I have implemented Gef "simple" keywords in the next 0.19 version of the EclipseLibrary.

The implementation is done for all of the keywords that use String or int parameters, not for complexes one using GefObjects at the moment.

I need to complete some tests and can send it to you for beta testing, if you don't mind?

Regards,

Laurent

2013/5/15 Laurent Carbonnaux <laurent.c...@gmail.com>

[Ricardo de Matos]

Bonjour Laurent,

Thank you! 

We will have a look.

Cheers!

Ricardo de Matos
忘れていない