vaadin-maven-plugin breaks filtering made by resource plugin and ignores va

Here is the module (vaadin UI) structure:

src
  - main
     - java
     - resources
         - VAADIN.themes
         - myproject.gwt.xml
     - webapp
         - WEB-INF

In order to strict gwt permutations I created a property that has different values depending on a build profile (gecko1_8 for debug and all permutations for production). So in order to replace property with a value I use resource filtering. But vaadin-maven-plugin copies (resources goal) gwt.xml file without changes. So if I remove resources goal - filtering works great. So here is how my module pom.xml looks like:

...
    <!--Artifact info-->
    <groupId>vaadin-ui</groupId>
    <artifactId>vaadin-ui</artifactId>
    <packaging>war</packaging>
    <version>1.0</version>
    <name>Vaadin UI</name>

    <!--Properties-->
	<properties>
		<project.build.sourceEncoding>UTF-8</project.build.sour		<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
		<vaadin.version>7.0.5</vaadin.version>
                        <gwt.restrict.user.agents>gecko1_8</gwt.restrict.user.agents>
	</properties>
    ...

    <!--Dependencies-->
	<dependencies>
		<dependency>
			<groupId>com.vaadin</groupId>
			<artifactId>vaadin-server</artifactId>
			<version>${vaadin.version}</version>
		</dependency>
		<dependency>
			<groupId>com.vaadin</groupId>
			<artifactId>vaadin-client-compiled</artifactId>
			<version>${vaadin.version}</version>
		</dependency>
		<dependency>
			<groupId>com.vaadin</groupId>
			<artifactId>vaadin-client</artifactId>
			<version>${vaadin.version}</version>
			<scope>provided</scope>
		</dependency>
		<dependency>
			<groupId>com.vaadin</groupId>
			<artifactId>vaadin-themes</artifactId>
			<version>${vaadin.version}</version>
		</dependency>
		<dependency>
			<groupId>javax.servlet</groupId>
			<artifactId>servlet-api</artifactId>
			<version>2.4</version>
			<scope>provided</scope>
		</dependency>

        <!--module dependency-->
        <dependency>
            <groupId>another-module</groupId>
            <artifactId>another-module</artifactId>
            <version>1.0-SNAPSHOT</version>
            <scope>provided</scope>
        </dependency>
      </dependencies>

      <build>
        <finalName>${project.artifactId}</finalName>
        <resources>
            <resource>
                <directory>${basedir}/src/main/resources</directory>
                <filtering>true</filtering>
                <includes>
                    <include>**/myproject.gwt.xml</include>
                </includes>
                <excludes>
                    <exclude>**/VAADIN.themes/*</exclude>
                </excludes>
            </resource>
            <resource>
                <directory>${basedir}/src/main/resources</directory>
                <filtering>false</filtering>
                <includes>
                    <include>**/VAADIN.themes/*</include>
                </includes>
                <excludes>
                    <exclude>**/myproject.gwt.xml</exclude>
                </excludes>
            </resource>
        </resources>
		<plugins>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-compiler-plugin</artifactId>
				<configuration>
					<source>1.6</source>
					<target>1.6</target>
				</configuration>
			</plugin>
			<!-- As we are doing "inplace" GWT compilation, ensure the widgetset -->
			<!-- directory is cleaned properly -->
			<plugin>
				<artifactId>maven-clean-plugin</artifactId>
				<version>2.4.1</version>
				<configuration>
					<filesets>
						<fileset>
							<directory>${basedir}/src/main/webapp/VAADIN/</directory>
						</fileset>
					</filesets>
				</configuration>
			</plugin>
			<plugin>
				<groupId>com.vaadin</groupId>
				<artifactId>vaadin-maven-plugin</artifactId>
				<version>${vaadin.version}</version>
				<configuration>
					<extraJvmArgs>-Xmx512M -Xss1024k</extraJvmArgs>
					<!-- We are doing "inplace" but into subdir VAADIN/widgetsets. This
						way compatible with Vaadin eclipse plugin. -->
					<webappDirectory>
                        ${basedir}/src/main/webapp/VAADIN/widgetsets
					</webappDirectory>
					<hostedWebapp>
                        ${basedir}/src/main/webapp/VAADIN/widgetsets
					</hostedWebapp>
					<noServer>true</noServer>
					<!-- Remove draftCompile when project is ready -->
					<draftCompile>false</draftCompile>
					<compileReport>true</compileReport>
					<style>OBF</style>
					<strict>true</strict>
					<runTarget>http://localhost:8080/</runTarget>
				</configuration>
				<executions>
					<execution>
						<configuration>
							<!-- if you don't specify any modules, the plugin will find them -->
							<!-- <modules> <module>com.vaadin.demo.mobilemail.gwt.ColorPickerWidgetSet</module> 
								</modules> -->
						</configuration>
						<goals>
							<goal>compile</goal>
						</goals>
					</execution>
				</executions>
			</plugin>
              ...
		</plugins>
	</build>
</project>

The problem is that in the end of a building process I get vaadin-ui.war file along with vaadin-ui-sources.jar, vaadin-ui-classes.jar and classes dir within target folder. And none of the jars or folders contain VAADIN/themes/. If I return goal resources to vaadin-maven-plugin, then VAADIN/themes/ are copied, but filtering stops working. After some experiments, I managed to get VAADIN/themes in classes folder but still it is absent in result .war file.
Why filtering doesn’t work with vaadin-maven-plugin? Maybe there’s a solution how to substitute properties and copy

Your resource filtering configuration uses VAADIN.themes rather than VAADIN/themes - is this correct? Are they copied to the right place?

Other than that, the order of execution of your own filtering and that performed by the Vaadin plug-in might be an issue. The Vaadin plug-in actually inherits the resources phase mojos from the GWT plug-in for Maven, and it should be safe to remove that lifecycle binding and rather copy resources yourself if needed (in many cases not necessary).

Yes, it is correct. You can use either VAADIN.themes or VAADIN/themes if there’s no files in between. I mean it is still like a package name VAADIN.themes. Maven translates it correctly.

If I use “mvn resources:resources”, my properties in gwt.xml are substituted correctly. If I use “mvn clean install”, properties in gwt.xml file are not filtered. I guess that they are but then “resources” phase of vaadin-maven-plugin copies them again without any filtering. If it is so, I need to turn in filtering at “resources” phase of vaadin plugin, but I cannot understand how to do it (there’s no info on vaadin-maven-plugin properties and its usage like for apache maven plugins), I can just blindly experiment.
As I’ve mentioned, if I remove “resources” lifecycle from vaadin plugin, then my filtering works great, but VAADIN/themes are not copied. Or I can remove my filtering, but I won’t be able to dynamically control properties values in gwt.xml (e.g. permutation amount).

I don’t know what exact info about my configuration can be helpful in order to solve this issue. Please, tell me and I share it with you.


updated

In fact all this filtering was done in order to control permutations amount. Maybe it is possible to restrict userAgents via plugin configuration? This way all resources will be copied and build process will be much faster :slight_smile:

I didn’t really have time to look deeper into filtering, but some other comments:

I agree that restricting userAgents via plugin configuration would be useful at times. Could you
create an enhancement request
about it.

One way to have effectively all permutations usable with the compilation time of a single permutation is to use
soft permutations
(in your widgetset, use

), which has the downside of a slightly bigger widgetset file to load (perhaps 10%) and a tiny (probably unnoticeable) performance impact for GWT.create(…) calls. The same problem with filtering occurs, though, unless you decide to also use this in production.

Another way to speed up widgetset compiles in the development environment is to use the draft compile mode, which can be enabled in the Maven plug-in configuration in your POM or development profile. It disables most optimizations, though.

Finally, using Maven WAR overlay projects to separate development and production settings might be an option as well.