Robot spoils SUT environment

[GoogleCodeExporter]

Issue Version:
javalib-core version- All
jvm -All
Operating System - Windows..

I would like to address some of the "serious" problems with Robot framework.

This is about the Robot Framework spoiling the application environment and
hiding/creating faults with the application.

Normally JVM Connector, Swing Library comes with lot of OEM's bundled inside.

Problems Observed:

1. When a SUT uses same OEM but different version of it, problem observed
in launching/functionality of the application
(i.e this observed with "avlon framework" where Swing/JVM connector uses
the older versions.)

2. When a SUT and Robot uses same OEM, but by mistake the OEM is not
packaged with SUT. In this case in a manual run of the application, the
application would fail due to missing of the OEM.

But when it is started with Robot Framwork "for Testing" it would hide the
error by providing the unpakaged OEM to the SUT to use and  hides a
"Critical fault"

These cases makes Robot Framework not reliable in Testing point of view,
why we are really spending the effort.

In my opinion the Robot Framework should be Thin and should not spoil the
SUT environment.

With Regards
Arul

Original issue reported on code.google.com by arulraj...@gmail.com on 14 Jan 2010 at 3:19

[GoogleCodeExporter]

I have never seen 'OEM' term used like this. From the context it seems you mean
external JAR packages. Is that correct guess?

Assuming you mean external JARs, could you please list what JARs are causing 
the problem?

Notice also that Robot Framework itself is not "spoiling" anything and it 
doesn't
even contain any Java code.

Original comment by pekka.klarck on 21 Jan 2010 at 2:25

[GoogleCodeExporter]

Hi,

I meant here the "OEM" as the third party jars packaged along with Robot 
Framework.

Below are the Jars had impacted some of out Tests

1. avalon-framework
2. xerces

In some cases after removing above jars from Robot jvmconnector.jar and
swinglibrary.jar only applications could be launched.

"Spoiling"
-----------
This is observed in a case with JRE 1.5 where a swing application hangs when it 
is
launched with Robot due to relative path (till now it is not clear how it is 
modified
by robot) to load a image file. When the application is getting launched 
manually,
the same works fine.

I think the above mentioned situations would have clarified your queries.

In my context "Robot framework" including all libraries and the complete 
environment.
Not only the python execution framework.

Please get back if you need more symptoms to resolve.

With regards
Arul
sada

Original comment by arulraj...@gmail.com on 25 Jan 2010 at 2:59

• Changed state: New

[GoogleCodeExporter]

We started to investigate can we use jarjar [1] tool to hide all the 
dependencies we
need in jvmconnector, swinglibrary, javalibcore. Let's hope it solves most of 
the
problems described.

[1] http://code.google.com/p/jarjar/

Original comment by jpran...@gmail.com on 26 Jan 2010 at 4:59

• Changed state: Accepted

[GoogleCodeExporter]

Hi,

Solution looks very promising and clean.

Thanks for your consideration and effort.

With regards
Arul

Original comment by arulraj...@gmail.com on 3 Feb 2010 at 4:35

[GoogleCodeExporter]

Could you try out the jvmconnector+RemoteApplications 1.0-rc1 with SwingLibrary 
1.1?
Does those work for you?

About the spoiling the environment you mention, do you mean that the working
directory is wrong? If yes do following: 
1. Use the exe, bat or any other srcipt that is normally used to start the
application also from the tests.
2. In case there is no above script, and application can be started only from 
one
directory, fix the application so that it can be started from any directory. 
3. In case 2. is not possible, create script that starts your application and 
makes
sure it is started from correct directory. Use then this script from tests to 
start
up the application.

All these are of course workarounds to your problem, but I think that it should 
be
possible to start any application from any directory, otherwise I count that as 
a 
bug in the application.

Original comment by jpran...@gmail.com on 11 Feb 2010 at 2:26

[GoogleCodeExporter]

Original comment by jpran...@gmail.com on 16 Feb 2010 at 11:39

• Added labels: Priority-Medium, Project-JvmConnector
• Removed labels: Priority-High, Project-JavalibCore

[GoogleCodeExporter]

There's a solution now and new versions of libraries has been released. Please
contact if the problem still persists.

Original comment by KariH...@gmail.com on 18 Feb 2010 at 8:56

• Changed state: Done