I took over the job of maintaining the selenium grid plugin. If this is the plugin you are talking about, Im sorry about not delivering a new release since I took over that job.
I'm in the middle of adding new configurations on available capabilities per configures nodes. Also, the problem about letting the user choose which version to use is not an easy task to solve because the version we have to include is added on slave/master boot and not on job launch. which would require a reboot of the node when you update the selenium version. I have an idea on how I can solve it though. I'd also prefer solution A but I'm more worried about the config improvement and the new addition than to fix the problem of keeping the version in sync which only involve and update in the pom and a redeploy of the plugin. My personal laptop I used to work on the plugin with has gone to repair so I'll have to setup my other computer so I can work on the plugin gain until I get my laptop back. I hope to release my first update of the plugin really soon. Sorry for the delay. Richard On 2012-07-22, at 14:33, Andrey Myatlyuk <[email protected]> wrote: > :-) > > I can see three options for improvement here, correct me if I'm wrong. > A) If it's possible, take Selenium core out of Selenium plugin and make the > core location configurable on client, thus making Jenkins user responsible > for keeping Selenium up to date. That will work if Selenium keeps API more or > less stable. > B) Add trigger for Selenium plugin build job to create a new release whenever > Selenium is updated. > C) Combine those two approaches, build new plugin for updated Selenium > version, but let the user to select Selenium installation, if desired. > > I personally like option A, but at the moment I don't have enough knowledge > about Selenium plugin to confirm that it will work :-) But I might spend some > time to look into it further. > > Andrey > > On Jul 22, 2012, at 5:15 AM, Linards Liepiņš <[email protected]> > wrote: > >> build moneky* :) >> >> 2012/7/22 Linards Liepiņš <[email protected]> >> Hmm .. I suppose some clarification/reminding of how stuff owrks will not >> harm here... >> >> Something must build/compile this selenium plugin. Usually this something is >> "build moneky". Usually these build monekys are most occupied people in >> whole development process because of several reasons - few of them you >> mentioned by yourself. For example - build automatization systems, >> therefore, build scripts have got no AI to automatically adapt to new >> changes made in api level of the dependewd software, therefore you have two >> options: >> >> - maintain you own compatability layer ( in the form of some kind of lib .. >> ) >> - force Selenium to pay someone willing to maintain it. Web Browser deves >> have no 3rd party interest in this ... :/ >> >> Therefore it the word "maintaining" is used ... it is not about willing - it >> is almost all the time about inconsistency on the release/version schedule >> and lack of documentation. >> >> >> 2012/7/22 Andrew Gray <[email protected]> >> Hi All, >> >> One of the biggest showstoppers for me is the incompatibility of the version >> of selenium embedded within the selenium plugin with browser versions >> changing so much. We are up to Chrome 22 or something and Firefox 14.0.1. >> >> My tests just fail because the jenkins plugin is not spawning the browser >> process to run the test. >> >> Is there a(n) (automated?) way we can get keep the Selenium Plugin up to >> date with browser releases? >> >> The Selenium Project seems to be able to release versions of selenium that >> keep pace with browsers >> >> Why can't the Selenium Plugin keep place with the latest release of Selenium >> (and therefore browsers)? >> >> Regards, >> >> Andrew >> >> >> >> -- >> A.C. Linards L. >> >> >> >> -- >> A.C. Linards L.
