Widgetset 'com.vaadin.DefaultWidgetSet' does not contain implementation for

I am using Vaadin Framework with Touchkit to develop an app for mobile browsers. I followed the instructions for a basic demonstration application; I used the Vaadin plugin for eclipse on my Windows 7 machine, and it worked fine the first time (I might say, also, that I had made several previous attempts at Vaadin demo apps, and this was the first one that went this smoothly). The app shows up in my default browser, Chrome, gives me a little message reminding me that this is not a phone, and runs.

I have made many modifications to this over the past week; I have dispensed with the example app’s opening view and replaced it with a navigationView, extended NavigationButton as I thought I needed to, etc. Everything continued to work fine. I was a little annoyed that it seemed that, to fix a bug, I had to (1) stop the server, (2) remove the app, (3) clean the work directory of the server (tomcat), (4) clean the server (whatever that option means); then I could change code, run maven install on the app, and re-run it on the server. If I skipped any of those steps, it seemed something would go wrong.

So this was a bit clumsy but worked. Then tonight I decided to attempt to streamline one or two of the debug options so that I wouldn’t have to right-click the project, select “Run As”, then select the maven install option. I also changed a small bit of the code.

Now, every time I run the application, I get the following message:

Widgetset ‘com.vaadin.DefaultWidgetSet’ does not contain implementation for com.vaadin.addon.touchkit.ui.NavigationManager. Check its component connector’s @Connect mapping, widgetsets GWT module description file and re-compile your widgetset. In case you have downloaded a vaadin add-on package, you might want to refer to add-on instructions.

I am not aware of having changed anything in the widgetset for the application. I did not add any addons; Touchkit is an add-on, I guess, but it has been getting compiled and running just fine scores of times for a week.

I read that I was supposed to “compile the widgetset”; most such references don’t say how to do that, and I haven’t had to do it before, separately, so I didn’t know (I may still not know). I finally found command-line instructions of

mvn vaadin:update-widgetset install

So I opened a command window and executed that – it seemed to run to completion and tell me it was OK – then went back to eclipse, refreshed the project, and ran again. It still gives that error. I guessed that if I put the second parameter from the command line down as a maven goal in the eclipse “debug as”/“maven build…” it would do it there, too; it seems to have done so, but running the application gives the same error message.

I found other helpful-sounding instructions that don’t seem to apply. One pointed the user to “web.xml”, except that I don’t have one.

Could changes to the source code of the server-side widgets have caused this, in any way? This has been working for a week, through many, many compilations and debug runs, I would think it has to be something small that changed, but how do I figure out what it is?

mvn clean install should run widgetset compilation. TouchKit is an addon so it needs widgset compilation only once (unless you clean your project). Changes in pom.xml might affect the need to compile widgetset if there are new addons in dependencies.

Also, you didn’t say where exactly you made those changes, so if you happen to have any local changes to client-side code, you’ll need a custom widgetset – you can add it e.g. by adding @Widgetset(“your.package.YourWidgetsetName”) to your UI class, no web.xml needed, and adding a MyWidgetsetName.gwt.xml to your.package within src/main/resources. Usual contents for that file are something along these lines, and the plugin should add the add-on dependencies automatically once you have the file in place:

[code]

<?xml version="1.0" encoding="UTF-8"?> [/code]You may also need to add some dependencies to the pom.xml. But again, all of this should only be necessary if you have local client-side classes.