On Fri, Oct 17, 2008 at 6:47 PM, Ray Cromwell <[EMAIL PROTECTED]> wrote:
> For trunk work, I'm personally not too concerned with this. I think > people compiling the trunk and living on the bleeding edge won't mind > upgrading their Firefox distributions, although I agree it might be an > issue when GWT 2.0 is ready for release. > My point was that some developers won't be in a position to upgrade to FF3 since it isn't really supported on their platform (any but the most current RHEL/CentOS, SUSE Enterprise, and others). If those developers are working off of trunk, merging OOPHM without FF1.5/2 support would cause them a real problem. > > Testing - existing hosted mode runs in headless by default, but since we > > aren't embedding the browser with OOPHM we can't easily do that. On Mac > and > > Windows that leads to a problem in that the window pops up and steals > > focus. Possibilities: > > Probably the easier way to handle this in Windows is to use a VM, > that's what we do today. We use Xvfb for Firefox tests, a VMWare XP > instance for IE tests, and a laptop or Mac Mini to run the OSX tests. > To some extent, this will all go away when OOPHM arrives. Our plan is > to run a single WinXP VMWare instance with selenium server which tests > Firefox, WebKit, Opera, and IE, since all of the required rendering > engines are available under Windows, with the exception of stuff like > the iPhone. I'm not sure of the legal issues, but it may be possible > to create a pre-configured VMWare player binary that contains a > selenium instance capable of being a remote GWT OOPHM test appliance. > Yeah, I don't think we can provide a Windows VM image :). > I advocate the VM approach for other reasons to, since you can't have > IE6/IE7/IE8 running side by side in a single WinXP instance, using VMs > allows you to test with multiple IE versions. > I like using VMs and that's how I test Windows (I don't even have a Windows install on native hardware), but I don't think it is reasonable to require developers to do that -- I think we need a decent story without requiring VMware/etc. > I hope we can finally retire all native libraries, and SWT code from > the GWT devjar distribution because it complicates a number of things: > 1) makes it hard for IDE vendors like JetBrains to integrate HM shell > directly into their IDE (they are Swing based) 2) Broke HM on Leopard > for a long time because of Carbon/SWT changes. 3) requires irritating > -XstartOnFirstThread parameter everywhere. 4) Breaks Maven Surefire > unit testing classloader 5) makes the gwt-maven plugin/config more > complex than it needs to be. > I agree -- I think we want to avoid it. However, some have suggested it as a solution to the testing problem so I included it. > If the old SWT based HM is to be maintained, can we package it in a > separate jar with a separate launcher so that other embeds of HM can > get away with ignoring it? > If it is done as just another OOPHM client, yes it could be distributed separately. I don't think that works as well if we do the switching at the BrowserWidget/ModuleSpace level. > You know what would be cool is if the selenium stuff + HM could > provision plugins remotely, so one doesn't have to go to all of ones > test instance servers and update the plugins whenever they change. I > don't know how feasible it would be, but minimally, some way of > probing the versions and notifying you which remote test browsers are > running old plugins would be useful. > Even if you do it as a two-stage process, you still need the "loader" plugin installed. On Safari, for example, there is no way for a browser plugin to even get loaded into memory with a page that references it. Adding a plugin that allows remote execution of native code without user acknowledgement (which you would need if you want to be able to install it remotely in a testing situation) seems like a bad idea. > I could see a future where perhaps someone updates a devjar containing > changes to the wire protocol, but has stale plugins (forgets to > upgrade some browser), and then runs into an obscure heisenbug. > The connect message includes the version so you will get a clear failure message on protocol version mismatch (or the server could conceivable support multiple versions if we decided we wanted to do that). -- John A. Tamplin Software Engineer (GWT), Google --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
