How does Vaadin recognize changes in the widgetset xml? (Maven)

I use Maven filtering to alter my widgetset xml file depending on the active profile. So far it works well, but for some reason the Vaadin Maven plugin thinks that the widgetset has to be compiled EVERY time I call the install phase.

Here are the relevant parts from my pom.xml:



And the part in my .gwt.xml that I filter:

<define-property name="buildprofile" values="dev,prod" />
<set-property name="buildprofile" value="${}" />
<set-property name="user.agent" value="gecko1_8">
    <when-property-is name="buildprofile" value="dev" />

How can I tell the Vaadin Maven plugin only to compile the widgetset when it has actually changed OR when I have switched the profile? Because now it compiles the widgetset even when the active profile and .gwt.xml contents stay untouched. I’m using Vaadin 7.1.0.

In your case i think it is recompiling it every time because of the variable ${}. Normally it should only recompile the widgetset if the xml somehow changed, for example when you add a dependency with a client-side widget but in your case you have a non-constant variable which needs to be filled everytime you compile the application because the compiler doesn’t “remember” the last value of this variable and then compares it to the new one.
You could try to temporarly exchange the variable with a constant string and see if it keeps recompiling (the first time you’re going to try it, it will of course recompile it because you changed the xml but after that if you don’t change anything else it should not compile).
If you need this variable but want to deactivate the recompiling because you know it’s not necessary you can comment out the necessary part of your pom.xml where it defines the update-widgetset goal (In Vaadin 6 it was the entire plugin block which defines the gwt compiler plugin and the one defining the maven plugin, i think).

I got a little deeper with this and found out that it’s the file timestamp that the plugin is watching… it still doesn’t solve my problem.

The plug-in (which inherits this part directly from the GWT plug-in) monitors file modification timestamps but for a large number of files, including source files that it monitors more aggressively than what it should.

The easy solution is to put the client side and widgetset compilation in a separate Maven module. That way, server side code changes will not force recompilation of the widgetset.

So… I guess I’ll just have to do some things manually.

I came to the conclusion that I cannot use the Maven resource filtering, because it will ALWAYS create a new file even though the contents remain unchanged. That will change the timestamp of the file and that, in turn, will trigger the GWT compilation.

I tried to create two widgetset files, but that didn’t work either because the vaadin:update-widgetset goal will in both build profiles inherit the wrong widgetset (ie. DevWidgetSet will be inherited in ProdWidgetSet and vice versa).

To avoid violating the DRY principle (=2 similar widgetset files), one could create a “CommonWidgetSet”, inherit that in DevWidgetSet and ProdWidgetSet and define custom properties in the two latter files. In this case DevWidgetSet and ProdWidgetSet need to tell the update-widgetset goal not to touch these files (ie. ). This method still has the problem that CommonWidgetSet will automatically inherit DevWidgetSet and ProdWidgetSet which isn’t acceptable.

I ended up creating two widgetset files which aren’t affected by the update-widgetsets goal. It’s not the optimal solution, but at least it solves the original problem. Now I just can’t use update-widgetsets goal anymore and have to manage addon widgetsets manually. That still requires less effort than having to edit the pom or widgetset every time I want to switch the build profile…

Haven’t you at Vaadin ran into same kind of situation?

Could you please describe your solution to this problem in more detail? Or perhaps could you create example project and host it on github or something like that?
I just ran into the same issue in one of my projects. I can filter everything for appropriate environment but i have to remember about the user.agent property. It would be very nice to be able to parameterize this property :slight_smile: