I recently installed FluentAutomation with selenium 2.32.1.0 from nuget. However, When I try to open a page using the I.Open("http://") method I get the following exception: Could not load file or assembly 'WebDriver, Version=2.25.1.0, Culture=neutral, PublicKeyToken=1c2bd1631853048f'
The FluentAutomation version in nuget says that it depends on Selenium.Support (≥ 2.25.1) which lead me to believe I could install 2.32.1.0. Does this mean that the FluentAutomation nuget package was built with a hard dependency on Selenium.Support 2.25 and I have to roll back my selenium components?
The issue here is the version of ChromeDriver.exe we package. The hard dependency is there. If you download the latest ChromeDriver.exe from Selenium and add it to your project (make sure it gets copied to the /bin directory), Fluent won't unpackage its own older copy and the mismatch problem should go away.
We are working on making this more transparent to the user and pulling latest into the project on setup, rather than packaging it into our DLLs.
(Author of FluentAutomation)
Related
We upgraded one of our Eclipse 3.x plugins to work with Java 9.
But when we generated the plugin update site content, and used Eclipse Update functionality to install the new version of the plugin, we encountered the following error in Eclipse Oxygen.
Removing part descriptor with the 'pluginxxx.bla.bla' id and the 'bla bla' description. Points to the invalid 'bundleclass://org.eclipse.ui.workbench/org.eclipse.ui.internal.e4.compatibility.CompatibilityView' class.
This error also appears due to some of the bundled plugins of Eclipse Oxygen itself.
After a hard week we had to
Uninstall our plugin
Remove the older versions of the plugin from the Eclipse/plugins folder
Export the plugin as a deployable plugin under the eclipse plugins directory. (Eclipse/plugins/blabla.jar)
Restart Eclipse and it worked.
Right click the eclipse plugin project and Run as "Eclipse Application" works fine, but installing the plugin from an "Update Site" causes the plugin to fail loading.
We could not find a solution yet, but it certainly effects our delivery of the plugin. The plugin is used by almost 500 CS students on their personal computers, and 200 lab computers. So the update should be installed using regular Eclipse Update functionality, not by copying the jar into the plugins directory.
Was there a better way to fix this, or something quicker we could've tried (in case this happens again)?
Update (7 days into the problem)
We have a workaround:
Export the feature project with the following settings in the Export Wizard
Destination/ Directory: Folder of your Plugin Update Site project
Options/ Package as individual JAR archieves (selected)
Options/ Generate p2 repository (selected)
Options/ Allow for binary cycles in target platform (selected)
Options/ Use class files compiled in the workspace (essentially selected)
Install (or update) the plugin from the local (or remote) plugin update site, and the CompatibilityView problem is solved.
In order to have the category listing displayed correctly during install/update new software operations, we added a category.xml file (File/New/Other/Plugin-in Development/Category Definition) in the update site project, defined the categories, and added the feature (versioned as "qualifier").
This is certainly not the way it should be, and we just hope it will be solved in the future Eclipse releases.
By the way current Eclipse Photon integration version has the same problem unfortunately.
I am working on developing test automation code in selenium, I want to use 'sikuli' inside my code to handle windows and Flash objects in my web application,
I'm using 64-bit JVM, but there is no 64-bit version of Sikuli available, this is resulting in an error while running the code,
"Can't load IA 32-bit .dll on a AMD 64-bit platform"
I could not find a 64-bit sikuli Jar on internet, but I found that Sikuli source code is hosted on GitHub, could someone help me understand if I can use that source code and compile it into a jar of 64 bit version?
I'm not sure if this is possible or not.
If you install Sikuli 1.0.1 you have the option to install 6 packages with it as well. I would recommend installing the first 5. Then you will have all the things you are ever going to use.
If you also work on different sytems other then Windows, the 6th packages is also advisable.
I have installed all 6.
Finally got this working, here is what I did,
Download the sikuli set-up Jar from
"https://launchpad.net/sikuli/sikulix/1.0.1/+download/sikuli-setup.jar"
Save this jar in a folder 'SikuliSetup',now create a sub directory
'Downloads' which will come into picture later.
Run the above Jar, this will generate two files under the above
directory.
Now run the 'runSetup.bat' file generated from above setup. This
will start the setup, now select the 4th and 6th option in the
'sikulisetup' pop-up and click on 'setup Now'.
The above step will fail for most people due to default security
issues.
If the above step fails then you need to download an offline
version of this jar from this URL
"https://launchpadlibrarian.net/156273987/Sukuli-1.0.1-Offline-Setup-Java-option3-option4.zip".
UnZip the above file and copy the '1.0.1-3.jar' file to 'Downloads'
directory created under the 'SikuliSetup' directory previously.
Now run the 'runSetup.bat' file again, this will generate a new
jar file 'sikuli-java' and its dependent libraries under 'lib'
folder.
That's it, now copy this jar 'sikuli-java.jar' to your java build
path in eclipse.
Now Java will use this sikuli libraries without any issues.
Once after you setup the jar file under build path, restart the
system and login again.
I added this plug in to my netbeans 7.2 IDE. Then, when I restarted the program and tried to open it again it did not open
as shown in this picture
I tried to restore my Windows system to previous restore point but the problem still exist.
any ideas how to solve this problem
I've tested the repository that they advised you to adding in the your Netbeans install.
But really has reference to many more plugins and features installed,
if you add this repository after upgrade the NetBeansIDE you will see that all base modules will have replaced by the development release and practically you will have another version of netbeans installed.
I advise you to uninstall your current netbeans without deleting your workspace and reinstall your netbeans downloaded directly from the official website.
And also I would advise you in the future should try the unofficial plugin in a test environment. before bringing in your work
environment
I'm developing an RCP project using Eclipse-Helios.
The version of SWT that is installed (in the plugins directory) is [org.eclipse.swt-win32-3.6.2, & org.eclipse.swt.jar]
I require new API functionality that is only available from swt-3.8. (specifically, I wish to set the custom colours, for an SWT color dialog before opening.)
I have downloaded 3.8.1 from the SWT/Eclipse downloads site [ http://download.eclipse.org/eclipse/downloads/drops/R-3.8-201206081200/#SWT ]
The SWT download is NOT a plugin (couple of jars, src.zip and some readme files), so I am unable to add it to my "Target Platform" (it doesn't appear as an available jar even after adding the containing directory in "locations")
I was unable to find an update site for SWT (or any site where i could get a plugin for the newer version)
If I add the swt.3.8.jar to my classpath (and then increase it's order-priority in the project build-path), I am able to access the newer api functionality from my code (as well as view the source).
When I run the application however, it seems as though the runtime is still using the older SWT jar, as i get an unknown method error, when attempting to access the newer functionality.
Questions:
Is there an SWT repository location that I can use to download a newer version of SWT using the eclipse install manager?
If not, is there a way I can force the runtime to ignore the older version (I assume via plugin.xml)?
Is there a better way to achieve what I am trying to do?
What is the difference between the two SWT jars currently in the helios plugins directory (as the 3.8 download only contains the win-32 version)?
Thanks in advance.
SWT is downloadable as a separate plugin here:
http://download.eclipse.org/eclipse/downloads/drops/R-3.8-201206081200/#SWT
Eclipse 3.8 contains regular plugins including the SWT (the win32 specific as well as the generic "org.eclipse.swt_.jar"). I am currently using the 3.8 version and they appear as plugins.
I also have Eclipse 3.6 (Helios) and I was able to import the swt plugins using the "File->Import->Plug-in Development->Plug-ins and Fragments" wizard. I just specified the eclipse 3.8 directory and could import them in my workspace. Once imported I can of-course use them to be included in the runtime environment. Eclipse should use the latest version automatically.
We are developing an Eclipse plugin for graphic editing of task graphs and then stores the serialized version in XML. We have used EMF and GMF to build our plugin, and were able to package and test it on win32 systems.
However, when we try to use install on other systems (64-bit windows, Linux), we get the
requires 'org.eclipse.core.filesystem.win32.x86[1.1.200.v20100505-1235]'
error.
We are not explicitly calling a win32 filesystem method, and I thought that although the plugin was developed on a win32 system, the plugin's dependency would only be on the org.eclipse.core.filesystem package, which would be resolved locally at install time on the user's machine.
Am I missing something? Should I edit a specific (autogenerated) file and remove the reference to the win32 package mention?
Thanks in advance for your time.
-A
org.eclipse.core.filesystem is the plugin and org.eclipse.core.filesystem.win32.x86 is a fragment. Ideally you should have dependency on the plugin only. How did the fragment end up as a dependency in your plugin? You can safely remove the fragment from your dependency