Important Notice - Forums is archived
To simplify things and help our users to be more productive, we have archived the current forum and focus our efforts on helping developers on Stack Overflow. You can post new questions on Stack Overflow or join our Discord channel.

Vaadin lets you build secure, UX-first PWAs entirely in Java.
Free ebook & tutorial.
Stepper with maven
I've unsuccessfully tried to add this add-on to an existing Vaading project using maven.
Does this add-on have the correct structure to be added in such a way?
There are many threads in the forum regarding maven add-on/widgetset problems. Is there a step-by-step procedure I can follow?
Here is how to use add-ons with maven in 10 steps. The steps below are untested, so please reply to the thread if I missed something.
1) download add-on jar
2) Using command line go to the directory where the jar file is located
3) Assuming that you just wanna store the dependency on your local repository you can run something like
mvn install:install-file -Dfile=nameOfAddOn-1.0.jar -DgroupId=org.your.group -DartifactId=someArtifactId -Dpackaging=jar -Dversion=1.0
4) Somewhere under src/main/java directory in your project add a GWT module descriptor file
For example make a package called org.your.group.gwt and then in there make a SomethingWidgetSet.gwt.xml
In this file add something like the following
<module>
<!--
This file is automatically updated based on new dependencies by the
goal "vaadin:update-widgetset".
Running the goals "gwt:clean gwt:compile" may be required to compile
the widgetset until http://jira.codehaus.org/browse/MGWT-148 is
resolved.
-->
<!--
This is needed because of a bug in gwt-maven-plugin 1.2
(http://jira.codehaus.org/browse/MGWT-147):
modules without entry points are never compiled.
-->
<entry-point class="com.vaadin.terminal.gwt.client.DefaultWidgetSet" />
<!-- Inherit DefaultWidgetSet -->
<inherits name="com.vaadin.terminal.gwt.DefaultWidgetSet" />
<!-- WidgetSet default theme -->
<!-- <stylesheet src="colorpicker/styles.css"/> -->
</module>
5) In the web.xml file for your project, something like the following should be present (this might not be strictly necessary, but doesn't hurt either)
<servlet>
<servlet-name>Vaadin Application Servlet</servlet-name>
<servlet-class>com.vaadin.terminal.gwt.server.ApplicationServlet</servlet-class>
<init-param>
<param-name>widgetset</param-name>
<param-value>org.your.group.gwt.SomethingWidgetSet</param-value>
</init-param>
</servlet>
6) If you made your project with the vaadin-archetype-sample, your pom file is more or less ready.
If you made your project with vaadin-archetype-clean then you have to uncomment the commented code.
It is probably a good idea to change vaadin dependency to 6.3 (it defaults to 6.2 at time of writing)
and gwt-user to 2.0.3 (it defaults to 1.7.1 at time of writing).
7) Also add a dependency to the addOn that we mavenized in step 3
Something like
<dependency>
<groupId>org.your.group</groupId>
<artifactId>someArtifactId</artifactId>
<version>1.0</version>
</dependency>
8) Now if you run a mvn clean vaadin:update-widgetset or even a mvn clean install
it should detect your addOn/widgetset and compile it.
If you see something like
[ERROR] Apr 27, 2010 7:01:03 PM com.vaadin.terminal.gwt.widgetsetutils.ClassPathExplorer getAvailableWidgetSets
[ERROR] INFO: Widgetsets found from classpath:
[ERROR] org.vaadin.henrik.refresher.RefresherApplicationWidgetset in jar:file:/.m2/repository/vaadin/addon/refresher/1.0/refresher-1.0.jar!/
[ERROR] org.your.group.gwt.SomethingWidgetSet in file:/workspace/myproject/src/main/java
[ERROR] com.vaadin.terminal.gwt.DefaultWidgetSet in jar:file:/.m2/repository/com/vaadin/vaadin/6.3.0/vaadin-6.3.0.jar!/
It is not actually an error. Just maven getting confused when it is doing info statements
9) Refresh your SomethingWidgetSet file and notice that there is a new line of text at the bottom referring to the addOn
10) You should now be able to use the addOn in your java code
I did not test this procedure, but overall it looks correct to me.
Note that steps 4-6 are only needed the first time, not when adding other add-ons to a project after the first. Furthermore, steps 4-5 are already done in the vaadin-archetype-sample, although redoing them (perhaps just copying files) to change the name of the widgetset might be useful.
So when adding a second add-on to a project, the steps are something like:
a) download the add-on and run mvn install:install-file to install the add-on to your local repository
b) add a dependency to the add-on
c) mvn clean vaadin:update-widgetset
d) refresh the project and use the add-on
Hi,
A new version (1.2.0) of the archetypes are out and they now default to Vaadin 6.3.1 and GWT 2.0.3.
I used the following process to verify that add-ons work with Maven and the new archetype:
1.
mvn archetype:generate -DarchetypeGroupId=com.vaadin -DarchetypeArtifactId=vaadin-archetype-widget -DarchetypeVersion=1.2.0 -DgroupId=mygroup -DartifactId=tst -Dversion=1.0
2. Download add-on e.g., playingcards-0.3.2.jar
3.
mvn install:install-file -Dfile=playingcards-0.3.2.jar -DgroupId=org.vaadin.artur -DartifactId=playingcards -Dpackaging=jar -Dversion=0.3.2
4. Add a dependency to the add-on to pom.xml:
<dependency>
<groupId>org.vaadin.artur</groupId>
<artifactId>playingcards</artifactId>
<version>0.3.2</version>
</dependency>
5. Add test code to see it works. Edit the application.java and add:
Card c = new Card(Suite.CLUBS,12);
window.addComponent(c);
6.
mvn vaadin:update-widgetset install
Sure hope we get Maven support for the Directory one day so you would get away with just adding the dependency to the pom.xml.
I can confirm that these steps worked for me and solved the problem I was having with trying to get an Add-On working. I was able to get this playingcards add on working and then was also able to get the VaadinVisualizations addon working as well in the same test project - which I had previously been struggling to get working.
One odd thing was that the first time I built this project I only did mvn install and got an error (which I didn't save sorry), but once I did mvn vaadin:update-widgetset install everything started to work properly. The other part to this that I can't explain is that when I tried to replicate the earlier problem by doing mvn clean install it didn't fail. So I'm not sure what's happening here but thought it might be worth mentioning that mvn vaadin:update-widgetset install is a good thing to try if you are having problems.
I updated to Vaadin 6.4.0 and ran into problems with the WidgetSet.
I saw in the vaadin-archetype-sample that gwt-maven-plugin version has been changed from 1.2 to 1.3 and that the <entry-point class="com.vaadin.terminal.gwt.client.DefaultWidgetSet" /> is no longer needed in the .gwt.xml file
You can see my gwt.xml file in my earlier post.
Is it correct that it now should only have the following:
<module>
<inherits name="com.vaadin.terminal.gwt.DefaultWidgetSet" />
<inherits name="org.vaadin.risto.stepper.widgetset.StepperWidgetset" />
</module>
Or am I mean to use a syntax as indicated on the 6.4.0 release notes
<replace-with class="com.example.MyExtendedWidgetSet">
<when-type-is class="com.vaadin.terminal.gwt.client.WidgetSet" />
</replace-with>
Could you please elaborate on how to use that syntax, or otherwise make it work?
What problems - or is it just that the instructions are not clear?
Some errors during widgetset compilation? Your widgets not getting included in the widgetset?
Benny Hjertaas: I updated to Vaadin 6.4.0 and ran into problems with the WidgetSet.
I saw in the vaadin-archetype-sample that gwt-maven-plugin version has been changed from 1.2 to 1.3 and that the <entry-point class="com.vaadin.terminal.gwt.client.DefaultWidgetSet" /> is no longer needed in the .gwt.xml file
You can see my gwt.xml file in my earlier post.
Is it correct that it now should only have the following:<module> <inherits name="com.vaadin.terminal.gwt.DefaultWidgetSet" /> <inherits name="org.vaadin.risto.stepper.widgetset.StepperWidgetset" /> </module>
This looks correct to me as the content of a widgetset. As you said, the entry point line should be removed (it was redundant already earlier, only needed as a workaround for a Maven GWT plugin bug) and you should use the 1.3-SNAPSHOT version of the Maven GWT plugin.
Benny Hjertaas: Or am I mean to use a syntax as indicated on the 6.4.0 release notes
<replace-with class="com.example.MyExtendedWidgetSet"> <when-type-is class="com.vaadin.terminal.gwt.client.WidgetSet" /> </replace-with>
This is only for very special cases where you do need to override functionality in the widgetset class.
If you don't know why you would need to do that, you probably don't need to do it.
Thanks for swift reply (as usual).
I've come a bit further...
When I run mvn clean install it compiles fine.
The problem is when using the maven-jetty plugin while pointing to the 1.3-SNAPSHOT version.
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>1.3-SNAPSHOT</version>
When you then call jetty:run
It fails with the following error:
Failed to execute goal org.mortbay.jetty:maven-jetty-plugin:6.1.24:run (default-cli) on project myProject: Unable to parse configuration of mojo org.mortbay.jetty:maven-jetty-plugin:6.1.24:run for parameter baseResource: Setter org.mortbay.resource.ResourceCollection.setResourcesAsCSV( java.lang.Class ) threw exception when called with parameter 'src/main/webapp,/home/benny/heliosWorkspace/myProject/target/myProject-1-SNAPSHOT': java.lang.IllegalArgumentException: file:/home/benny/heliosWorkspace/myProject/target/myProject-1-SNAPSHOT is not an existing directory. InvocationTargetException
I understand this is more a maven problem than a vaadin problem, but perhaps you've seen it before
It seems like it is the 1.3-SNAPSHOT version of gwt-maven-plugin that does not compile the widgetset, and that is why I get that error I mentioned before (since the path ...myProject/target/myProject-1-SNAPSHOT is never made).
When using 1.2-SNAPSHOT the output is:
.
.
.
--- maven-resources-plugin:2.4.1:resources (default-resources) @ myProject ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /home/bhj/heliosWorkspace/myProject/src/main/resources
[INFO]
[INFO] --- gwt-maven-plugin:1.2-SNAPSHOT:resources (default) @ myProject ---
[INFO] auto discovered modules [broadway.myProject.gwt.myProjectWidgetSet]
[INFO] 1 source files copied from GWT module broadway.myProject.gwt.myProjectWidgetSet
[INFO]
[INFO] --- maven-compiler-plugin:2.0.2:compile (default-compile) @ myProject ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- gwt-maven-plugin:1.2-SNAPSHOT:compile (default) @ myProject ---
[INFO] using GWT jars from project dependencies : 2.0.3
[INFO] auto discovered modules [broadway.myProject.gwt.myProjectWidgetSet]
[INFO] establishing classpath list (scope = compile)
[INFO] Compiling module broadway.myProject.gwt.myProjectWidgetSet
[INFO] Scanning for additional dependencies: jar:file:/home/bhj/.m2/repository/com/vaadin/vaadin/6.3.4/vaadin-6.3.4.jar!/com/vaadin/terminal/gwt/client/DefaultWidgetSet.java
[INFO] Computing all possible rebind results for 'com.vaadin.terminal.gwt.client.WidgetMap'
[INFO] Rebinding com.vaadin.terminal.gwt.client.WidgetMap
[INFO] Invoking com.google.gwt.dev.javac.StandardGeneratorContext@88d1f2
[INFO] Detecting Vaadin components in classpath to generate WidgetMapImpl.java ...
[INFO] Widget set will contain implementations for following components:
[INFO] com.vaadin.ui.AbsoluteLayout
[INFO] com.vaadin.ui.Accordion
[INFO] com.vaadin.ui.Button
[INFO] com.vaadin.ui.CheckBox
[INFO] com.vaadin.ui.ComboBox
.
.
.
When using 1.3-SNAPSHOT the output is:
.
.
.
[INFO] --- maven-resources-plugin:2.4.1:resources (default-resources) @ myProject ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /home/bhj/heliosWorkspace/myProject/src/main/resources
[INFO]
[INFO] --- gwt-maven-plugin:1.3-SNAPSHOT:resources (default) @ myProject ---
[INFO] auto discovered modules [broadway.myProject.gwt.myProjectWidgetSet]
[INFO] 1 source files copied from GWT module broadway.myProject.gwt.myProjectWidgetSet
[INFO]
[INFO] --- maven-compiler-plugin:2.0.2:compile (default-compile) @ myProject ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- vaadin-maven-plugin:1.0.0:update-widgetset (default) @ myProject ---
[INFO] auto discovered modules [broadway.myProject.gwt.myProjectWidgetSet]
[INFO] Updating widgetset broadway.myProject.gwt.myProjectWidgetSet
[INFO] establishing classpath list (scope = compile)
[ERROR] Jul 15, 2010 3:28:51 PM com.vaadin.terminal.gwt.widgetsetutils.ClassPathExplorer getAvailableWidgetSets
[ERROR] INFO: Widgetsets found from classpath:
[ERROR] org.vaadin.henrik.refresher.RefresherApplicationWidgetset in jar:file:/home/bhj/.m2/repository/vaadin/addon/refresher/1.0/refresher-1.0.jar!/
[ERROR] broadway.myProject.gwt.myProjectWidgetSet in file:/home/bhj/heliosWorkspace/myProject/src/main/java
[ERROR] com.vaadin.terminal.gwt.DefaultWidgetSet in jar:file:/home/bhj/.m2/repository/com/vaadin/vaadin/6.4.0/vaadin-6.4.0.jar!/
[ERROR] org.vaadin.risto.stepper.widgetset.StepperWidgetset in jar:file:/home/bhj/.m2/repository/vaadin/addon/stepper/0.3/stepper-0.3.jar!/
[ERROR]
[INFO]
[INFO] --- maven-resources-plugin:2.4.1:testResources (default-testResources) @ myProject ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /home/bhj/heliosWorkspace/myProject/src/test/resources
[INFO]
[INFO] --- maven-compiler-plugin:2.0.2:testCompile (default-testCompile) @ myProject ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- maven-jetty-plugin:6.1.24:run (default-cli) @ myProject ---
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
.
.
.
Notice that in the latter output, the widgetset is found, but not compiled. And It prints vaadin-maven-plugin:1.0.0:update-widgetset instead of gwt-maven-plugin:1.2-SNAPSHOT:compile
I cannot use version 1.2-SNAPSHOT with vaadin 6.4.0 either. It fails with the following output:
.
.
.
[INFO] --- gwt-maven-plugin:1.2-SNAPSHOT:compile (default) @ playbill ---
[INFO] using GWT jars from project dependencies : 2.0.3
[INFO] auto discovered modules [broadway.playbill.gwt.PlaybillWidgetSet]
[INFO] establishing classpath list (scope = compile)
[INFO] Compiling module broadway.playbill.gwt.PlaybillWidgetSet
[INFO] Finding entry point classes
[INFO] [ERROR] Unable to find type 'com.vaadin.terminal.gwt.client.DefaultWidgetSet'
[INFO] [ERROR] Hint: Check that the type name 'com.vaadin.terminal.gwt.client.DefaultWidgetSet' is really what you meant
[INFO] [ERROR] Hint: Check that your classpath includes all required source roots
.
.
[ERROR] Failed to execute goal org.codehaus.mojo:gwt-maven-plugin:1.2-SNAPSHOT:compile (default) on project playbill: Command
.
.
.
.
Could it be that when you used 1.2, it left the timestamps of the compiled widgetset such that 1.3 thinks nothing has changed. If so, you could try mvn clean, or maybe touching the widgetset.gwt.xml file or manually removing the compiled widgetset.
I put this problem on hold for a while, but tried again now with Vaadin 6.4.1, still without luck.
It works like a charm when running
mvn install
or
clean vaadin:update-widgetset install jetty:run
.. etc
as long as you have the install goal, it compiles the widgetsets.
But when the install goal is used, the hot-deploy in the maven-jetty-plugin (scanIntervalSeconds) doesn't work. So it becomes rather tedious to write UI code.
When using Vaadin 6.3.4 (or earlier) and gwt-maven-plugin version 1.2-SNAPSHOT I just did a jetty:run and code+widgetsets were compiled and put in the target directory, where the maven-jetty-plugin picks it up.
Vaadin 6.4 and newer seems to be require gwt-maven-plugin 1.3-SNAPSHOT.
But version 1.3-SNAPSHOT must work slightly differently, because it does not compile and produce a war file in the target directory when doing jetty:run. And hence, the maven-jetty-plugin failes with an IllegalArgumentException: file:/blah/somedir/target/projectName-1-SNAPSHOT is not an existing directory.
The question:
Why is Vaadin 6.4+ not compatible with gwt-maven-plugin version 1.2-SNAPSHOT which was working fine? (At least with the entry-point in the gwt.xml file)
Or even better, if you can figure out why gwt-maven-plugin 1.3-SNAPSHOT doesn't build the war file unless you run the install goal, that would be fantastic.
Benny Hjertaas: It works like a charm when running
mvn install
or
clean vaadin:update-widgetset install jetty:run
.. etcas long as you have the install goal, it compiles the widgetsets.
But when the install goal is used, the hot-deploy in the maven-jetty-plugin (scanIntervalSeconds) doesn't work. So it becomes rather tedious to write UI code.When using Vaadin 6.3.4 (or earlier) and gwt-maven-plugin version 1.2-SNAPSHOT I just did a jetty:run and code+widgetsets were compiled and put in the target directory, where the maven-jetty-plugin picks it up.
This is more of a Maven issue than a Vaadin issue, but the Vaadin archetypes could be updated at some point if there are better ways to do things.
Does it work if you use
mvn vaadin:update-widgetset package jetty:run
or
mvn vaadin:update-widgetset gwt:compile package jetty:run
You can also tell the jetty plugin to monitor additional directories with the scanTargets and scanTargetPatterns parameters etc. - see the plugin documentation.
Benny Hjertaas:
Vaadin 6.4 and newer seems to be require gwt-maven-plugin 1.3-SNAPSHOT.
But version 1.3-SNAPSHOT must work slightly differently, because it does not compile and produce a war file in the target directory when doing jetty:run. And hence, the maven-jetty-plugin failes with an IllegalArgumentException: file:/blah/somedir/target/projectName-1-SNAPSHOT is not an existing directory.The question:
Why is Vaadin 6.4+ not compatible with gwt-maven-plugin version 1.2-SNAPSHOT which was working fine? (At least with the entry-point in the gwt.xml file)
Or even better, if you can figure out why gwt-maven-plugin 1.3-SNAPSHOT doesn't build the war file unless you run the install goal, that would be fantastic.
The plugin version 1.2 also had some other problems, e.g. not recompiling the widgetset if only the GWT module file had changed. On the other hand, 1.3-SNAPSHOT (and probably also 1.2) does seem to be too aggressive in recompiling the widgetset in Vaadin projects when only server-side code changes - this needs to be investigated in more detail.
In Vaadin 6.4, the entry point (which was deprecated already a long time ago in Vaadin widgetsets) is no longer supported the way it used to be.
Thanks for detailed reply and good suggestions.
Using the 'package' goal makes it work, but hot-deploy does not. When I have time I will investigate further, and post the working solution here.
Got it!
1) It is no longer possible to simply run jetty:run. You must do gwt:compile jetty:run
2) In the vaadin-sample archetype there is an error in the gwt-maven-plugin configuration. The <configuration> tag and its contents should not be enclosed in <executions><execution>. When it is there, the <webappDirectory> is simply ignored, and vaadin cannot find the widgetsets.
So it should look something like this
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>1.3-SNAPSHOT</version>
<configuration>
<!-- if you don't specify any modules, the plugin will find them -->
<modules>
<module>path.to.my.gwt.WidgetSet</module>
</modules>
<webappDirectory>${project.build.directory}/${project.build.finalName}/VAADIN/widgetsets</webappDirectory>
<!-- On Mac running Snow Leopard, add "-d32" -->
<!-- This causes error messages (but build works) in phase "package":
two processes would use the same debug port -->
<!--extraJvmArgs>-Xmx512M -Xss1024k -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8998</extraJvmArgs -->
<extraJvmArgs>-Xmx512M -Xss1024k</extraJvmArgs>
<runTarget>playbill</runTarget>
<hostedWebapp>${project.build.directory}/${project.build.finalName}</hostedWebapp>
<noServer>true</noServer>
<port>8080</port>
<soyc>false</soyc>
</configuration>
<executions>
<execution>
<goals>
<goal>resources</goal>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
Do that, run the above command and voila. Widgetsets and hotdeploy works.
Benny Hjertaas: 2) In the vaadin-sample archetype there is an error in the gwt-maven-plugin configuration. The <configuration> tag and its contents should not be enclosed in <executions><execution>. When it is there, the <webappDirectory> is simply ignored, and vaadin cannot find the widgetsets.
Thanks for pointing this out.
This should be fixed in the archetype versions 1.3.2 to be released later today or tomorrow, could you also give them a spin once they are out.
Hi,
I'm running into a problem getting my project build under linux with version 6.4.4 of vaadin jar, using gwt version 2.0.4.
I have a utility project with package structure:
src/main/java
|
|--com.tnt.vaadin.widgetset
| |
| |--Refresher.java
| |--RefresherApplicationWidgetSet.gwt.xml
|
|--com.tnt.vaadin.widgetset.client.ui
| |
| |--VRefresher.java
I'm using the following configuration within the pom file of this project (this is not a web project, but a utility jar, so the project.build.directory is actually target):
<build>
<plugins>
<!-- Compiles your custom GWT components with the GWT compiler -->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>1.3-SNAPSHOT</version>
<configuration>
<!-- if you don't specify any modules, the plugin will find them -->
<modules>
<module>com.tnt.vaadin.widgetset.RefresherApplicationWidgetSet</module>
</modules>
<webappDirectory>${project.build.directory}/classes/VAADIN/widgetsets</webappDirectory>
<extraJvmArgs>-Xmx512M -Xss1024k</extraJvmArgs>
<runTarget>clean</runTarget>
</configuration>
<executions>
<execution>
<goals>
<goal>resources</goal>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- Updates Vaadin widgetset definitions based on project dependencies. -->
<plugin>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-maven-plugin</artifactId>
<version>1.0.1</version>
<executions>
<execution>
<configuration>
<!-- If you don't specify any modules, the plugin will find them. -->
<modules>
<module>com.tnt.vaadin.widgetset.RefresherApplicationWidgetSet</module>
</modules>
</configuration>
<goals>
<goal>update-widgetset</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin</artifactId>
<version>6.4.4</version>
</dependency>
<dependency>
<groupId>org.vaadin.henrik</groupId>
<artifactId>refresher</artifactId>
<version>1.0.0</version>
</dependency>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-user</artifactId>
<version>2.0.4</version>
</dependency>
</dependencies>
Building the project using 'mvn clean install' works fine when running under Windows: the generated files are compiled to target/classes/VAADIN/widgetsets and they are also packaged in the final jar file being build.
However, when I run the build on our linux build server (which does an 'mvn deploy'), the compilation of the widget fails with a message:
GWT Module src.main.java.com.tnt.vaadin.widgetset.RefresherApplicationWidgetSet not found in project sources or resources
When I go back to Vaadin jar 6.3.4 and gwt version 2.0.3, it both compiles under windows and linux.
Any idea why this is going wrong under linux using Vaadin jar version higher than 6.3.4? It seems that Vaadin jar adds the src/main/java source folder in front of the package, which I think it should not do.
Is there a work around to get this working under linux?
Kind regards,
Manfred
Manfred Schürhoff: Building the project using 'mvn clean install' works fine when running under Windows: the generated files are compiled to target/classes/VAADIN/widgetsets and they are also packaged in the final jar file being build.
However, when I run the build on our linux build server (which does an 'mvn deploy'), the compilation of the widget fails with a message:
GWT Module src.main.java.com.tnt.vaadin.widgetset.RefresherApplicationWidgetSet not found in project sources or resourcesWhen I go back to Vaadin jar 6.3.4 and gwt version 2.0.3, it both compiles under windows and linux.
Any idea why this is going wrong under linux using Vaadin jar version higher than 6.3.4? It seems that Vaadin jar adds the src/main/java source folder in front of the package, which I think it should not do.
Is there a work around to get this working under linux?
I assume "mvn clean vaadin:update-widgetset gwt:compile" on the linux server does not help.
For GWT compilation to work, the source folder has to be on the classpath. The Vaadin Maven plugin can create a widgetset if it does not exist, but creates it in the first directory on the classpath - if the widgetset already exists, the order of the classpath does not matter for it.
Why this directory is added as a part of the package path is not clear to me, and might have something to do with having the root of the project on the classpath before the source directory - but how to control this, and why it stopped working? The changes in WidgetSetBuilder, at least, are quite small between these versions, and you seem to be using the same version of the Vaadin Maven plugin.
At what phase does this problem occur? Updating the widgetset or compiling it?
If it is related to the widgetset update, you could try moving the configuration section outside of the executions section. You could also try to isolate this by changing only the Vaadin version or only the GWT version, and checking what breaks this.
Henri Sara:
Manfred Schürhoff: Building the project using 'mvn clean install' works fine when running under Windows: the generated files are compiled to target/classes/VAADIN/widgetsets and they are also packaged in the final jar file being build.
However, when I run the build on our linux build server (which does an 'mvn deploy'), the compilation of the widget fails with a message:
GWT Module src.main.java.com.tnt.vaadin.widgetset.RefresherApplicationWidgetSet not found in project sources or resourcesWhen I go back to Vaadin jar 6.3.4 and gwt version 2.0.3, it both compiles under windows and linux.
Any idea why this is going wrong under linux using Vaadin jar version higher than 6.3.4? It seems that Vaadin jar adds the src/main/java source folder in front of the package, which I think it should not do.
Is there a work around to get this working under linux?Henri Sara: I assume "mvn clean vaadin:update-widgetset gwt:compile" on the linux server does not help.
This doesn't help indeed.
Henri Sara: For GWT compilation to work, the source folder has to be on the classpath. The Vaadin Maven plugin can create a widgetset if it does not exist, but creates it in the first directory on the classpath - if the widgetset already exists, the order of the classpath does not matter for it.
I debugged the vaadin-maven-plugin version 1.0.1 and the source folder containing the widget and gwt.xml files are on the classpath. The actually command being executed is:
/bin/sh -c /usr/java/jdk1.5.0_14/jre/bin/java -Xmx512m -classpath [b]"/usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/src/main/java":[/b] "/usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/src/main/generated": "/usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/src/main/resources": "/usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/${sourceDirectory}": "/usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/ejbModule": "/usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/target/classes": "/home/tomcat/.m2/repository/com/vaadin/vaadin/6.4.4/vaadin-6.4.4.jar": "/home/tomcat/.m2/repository/org/vaadin/henrik/refresher/1.0.0/refresher-1.0.0.jar": "/home/tomcat/.m2/repository/com/google/gwt/gwt-user/2.0.4/gwt-user-2.0.4.jar": "/home/tomcat/.m2/repository/cglib/cglib/2.2/cglib-2.2.jar": "/home/tomcat/.m2/repository/asm/asm/3.1/asm-3.1.jar": "/home/tomcat/.m2/repository/com/tnt/tech-tc/Tech-SharedUtils-Dvn/1.0.15-SNAPSHOT/Tech-SharedUtils-Dvn-1.0.15-SNAPSHOT.jar": "/home/tomcat/.m2/repository/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar": "/home/tomcat/.m2/repository/joda-time/joda-time/1.6/joda-time-1.6.jar": "/home/tomcat/.m2/repository/com/tnt/tech-tc/Tech-Hibernate-Dvn/1.1.3/Tech-Hibernate-Dvn-1.1.3.jar": "/home/tomcat/.m2/repository/com/tnt/tech-tc/Tech-Util-Dvn/2.01.109/Tech-Util-Dvn-2.01.109.jar": "/home/tomcat/.m2/repository/com/tnt/cct/cct-exceptions/1.1.07/cct-exceptions-1.1.07.jar" [b]com.vaadin.terminal.gwt.widgetsetutils.WidgetSetBuilder[/b] [b]com.tnt.vaadin.widgetset.RefresherApplicationWidgetSet[/b]
So it seems the plugin is working OK.
I haven't been able to debug the WidgetSetBuilder or any of the other classes withing the Vaadin.jar yet because the plugin excutes it in a separate process.
Henri Sara: Why this directory is added as a part of the package path is not clear to me, and might have something to do with having the root of the project on the classpath before the source directory - but how to control this, and why it stopped working? The changes in WidgetSetBuilder, at least, are quite small between these versions, and you seem to be using the same version of the Vaadin Maven plugin.
The root of the project doesn't seem to be on the classpath.
Henri Sara: At what phase does this problem occur? Updating the widgetset or compiling it?
It looks like it is failing in the compilation phase.
The output of maven is as follows:
[tomcat@NLGHOL04 374e58a11dfb42db]$ mvnDebug clean install -Denforcer.skip=true -Dmaven.test.skip=true
Preparing to Execute Maven in Debug Mode
Listening for transport dt_socket at address: 8000
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building Technical Component: Vaadin Framework
[INFO] task-segment: [clean, install]
[INFO] ------------------------------------------------------------------------
[INFO] [clean:clean {execution: default-clean}]
[INFO] Deleting directory /usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/target
[INFO] Deleting directory /usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/target/classes
[INFO] Deleting directory /usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/target/test-classes
[INFO] Deleting directory /usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/target/site
[INFO] [enforcer:enforce {execution: default}]
[INFO] Skipping Rule Enforcement.
[INFO] [build-helper:add-source {execution: add-source}]
[INFO] Source directory: /usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/src/main/generated added.
[INFO] [utils:executePlugin {execution: ejb-versionif-execution}]
[INFO] Executing goal updateVersion within execution updateVersionIF for plugin Plugin [com.tnt.maven.plugins:maven-versionif-plugin]
[INFO] [versionif:updateVersion {execution: updateVersionIF}]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using default encoding to copy filtered resources.
[INFO] [gwt:resources {execution: default}]
[INFO] auto discovered modules [com.tnt.vaadin.widgetset.RefresherApplicationWidgetSet]
[INFO] 1 source files copied from GWT module com.tnt.vaadin.widgetset.RefresherApplicationWidgetSet
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 32 source files to /usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/target/classes
[INFO] [utils:executePlugin {execution: aspectJ-weaving-execution}]
[INFO] [vaadin:update-widgetset {execution: default}]
[INFO] auto discovered modules [com.tnt.vaadin.widgetset.RefresherApplicationWidgetSet]
[INFO] Updating widgetset com.tnt.vaadin.widgetset.RefresherApplicationWidgetSet
[INFO] establishing classpath list (scope = compile)
[ERROR] Sep 24, 2010 10:11:11 AM [b]com.vaadin.terminal.gwt.widgetsetutils.ClassPathExplorer getAvailableWidgetSets[/b][ERROR] INFO: Widgetsets found from classpath:
[ERROR] com.vaadin.terminal.gwt.DefaultWidgetSet in jar:file:/home/tomcat/.m2/repository/com/vaadin/vaadin/6.4.4/vaadin-6.4.4.jar!/
[ERROR] org.vaadin.henrik.refresher.RefresherApplicationWidgetset in jar:file:/home/tomcat/.m2/repository/org/vaadin/henrik/refresher/1.0.0/refresher-1.0.0.jar!/
[ERROR] [b]src.main.java.[/b]com.tnt.vaadin.widgetset.RefresherApplicationWidgetSet in file:/usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db
[ERROR] target.classes.com.tnt.vaadin.widgetset.RefresherApplicationWidgetSet in file:/usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db
[ERROR] com.tnt.vaadin.widgetset.RefresherApplicationWidgetSet in file:/usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/src/main/java
[ERROR] [b]src.main.resources[/b].com.tnt.vaadin.widgetset.RefresherApplicationWidgetSet in file:/usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db
[ERROR]
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Not compiling test sources
[INFO] [surefire:test {execution: default-test}]
[INFO] Tests are skipped.
[INFO] [gwt:compile {execution: default}]
[INFO] using GWT jars from project dependencies : 2.0.4
[INFO] auto discovered modules [com.tnt.vaadin.widgetset.RefresherApplicationWidgetSet]
[INFO] establishing classpath list (scope = compile)
[INFO] establishing classpath list (scope = compile)
[INFO] establishing classpath list (scope = compile)
[INFO] establishing classpath list (scope = compile)
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] GWT Module src.main.java.com.tnt.vaadin.widgetset.RefresherApplicationWidgetSet not found in project sources or resources.
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 28 seconds
[INFO] Finished at: Fri Sep 24 08:11:15 UTC 2010
[INFO] Final Memory: 31M/253M
[INFO] ------------------------------------------------------------------------
Henri Sara: If it is related to the widgetset update, you could try moving the configuration section outside of the executions section.
I've moved the configuration outside the execution tags, but that doesn't help.
Henri Sara: You could also try to isolate this by changing only the Vaadin version or only the GWT version, and checking what breaks this.
I left Vaadin version 6.3.4 and changed GWT version to 2.0.3 and 2.0.4. No problem.
Changing to Vaadin version 6.4.4 fails (both with version 2.0.3 or 2.0.4 of GWT version).
Henri Sara: The changes in WidgetSetBuilder, at least, are quite small between these versions, and you seem to be using the same version of the Vaadin Maven plugin.
In the updateWidgetSet method in the WidgetSetBuilder class, the following code is executed:
Map<String, URL> availableWidgetSets = ClassPathExplorer.getAvailableWidgetSets();
It seems that the getAvailableWidgetSets has been significantly changed between the two versions. Could something be going wrong here? Maybe in this part it adds src.main.java before the package when it runs under Linux?
Hi,
I think your problem is the classpath entry
"/usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/${sourceDirectory}"
As you are running the compile using "/bin/sh -c" the shell will try to replace ${sourceDirectory} with the sourceDirectory variable. As it is not defined it will be replaced by an empty string and the result is that you have
/usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/
on the classpath and the extra directories will therefore also be scanned.
You should also be able to verify this by increasing the log level and looking at the "classpathLocations values:" output logged by ClassPathExplorer. This contains the actual classpath that it uses.
Hi,
Thanks for looking into this.
We received a vaadin-6.4.6.dev20101005.jar with the ClassPathExplorer from the 6.3 branch, and this seemed to work for us. But I think this is just because the order of scanning the class folders is different in this version.
So what we need to do is setup a sourceDirectory variable for our buildplan in TeamCity I guess?
Or is this something we should configure in the pom file for the gwt-maven-plugin or vaadin-maven-plugin? Which one is establishing this classpath.
I've run the build in debug mode, and it seems that sourceDirectory is resolved to /usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/src/main/java, which seems OK to me.
But GWT SDK execution classpath contains /usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/${sourceDirectory}:
[05:57:45]: [DEBUG] Configuring mojo 'com.vaadin:vaadin-maven-plugin:1.0.1:update-widgetset' -->
[05:57:45]: [DEBUG] (f) extraJvmArgs = -Xmx512m
[05:57:45]: [DEBUG] (f) modules = [com.tnt.vaadin.widgetsets.TNTRefresherApplicationWidgetset]
[05:57:45]: [DEBUG] (f) project = MavenProject: com.tnt.tech-tc:Tech-VaadinFramework:1.0.0-SNAPSHOT @ /usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/pom.xml
[color=#0000FF][b][05:57:45]: [DEBUG] (f) sourceDirectory = /usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/src/main/java[/b][/color]
[05:57:45]: [DEBUG] -- end configuration --
[05:57:45]: [INFO] [vaadin:update-widgetset {execution: default}]
[05:57:45]: [INFO] Updating widgetset com.tnt.vaadin.widgetsets.TNTRefresherApplicationWidgetset
[05:57:45]: [INFO] establishing classpath list (scope = compile)
[05:57:45]: [DEBUG] candidate artifacts : 14
[05:57:45]: [DEBUG] GWT SDK execution classpath :
[05:57:45]: [DEBUG] /usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/src/main/java
[05:57:45]: [DEBUG] /usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/src/main/generated
[05:57:45]: [DEBUG] /usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/src/main/resources
[color=#0000FF][b][05:57:45]: [DEBUG] /usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/${sourceDirectory}[/b][/color]
[05:57:45]: [DEBUG] /usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/ejbModule
[05:57:45]: [DEBUG] /usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/target/classes
[05:57:45]: [DEBUG] /home/tomcat/.m2/repository/com/vaadin/vaadin/6.4.6.dev20101005/vaadin-6.4.6.dev20101005.jar
[05:57:45]: [DEBUG] /home/tomcat/.m2/repository/org/vaadin/henrik/refresher/1.0.0/refresher-1.0.0.jar
[05:57:45]: [DEBUG] /home/tomcat/.m2/repository/com/google/gwt/gwt-user/2.0.4/gwt-user-2.0.4.jar
[05:57:45]: [DEBUG] /home/tomcat/.m2/repository/cglib/cglib/2.2/cglib-2.2.jar
[05:57:45]: [DEBUG] /home/tomcat/.m2/repository/asm/asm/3.1/asm-3.1.jar
[05:57:45]: [DEBUG] /home/tomcat/.m2/repository/com/tnt/tech-tc/Tech-SharedUtils-Dvn/1.0.16-SNAPSHOT/Tech-SharedUtils-Dvn-1.0.16-SNAPSHOT.jar
[05:57:45]: [DEBUG] /home/tomcat/.m2/repository/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar
[05:57:45]: [DEBUG] /home/tomcat/.m2/repository/joda-time/joda-time/1.6/joda-time-1.6.jar
[05:57:45]: [DEBUG] /home/tomcat/.m2/repository/com/tnt/tech-tc/Tech-Hibernate-Dvn/1.1.3/Tech-Hibernate-Dvn-1.1.3.jar
[05:57:45]: [DEBUG] /home/tomcat/.m2/repository/com/tnt/tech-tc/Tech-Util-Dvn/2.01.109/Tech-Util-Dvn-2.01.109.jar
[05:57:45]: [DEBUG] /home/tomcat/.m2/repository/com/tnt/cct/cct-exceptions/1.2.2/cct-exceptions-1.2.2.jar
[05:57:45]: [DEBUG] /home/tomcat/.m2/repository/com/tnt/cct/cct-public/1.2.3/cct-public-1.2.3.jar
[05:57:45]: [DEBUG] /home/tomcat/.m2/repository/com/tnt/cct/cct-private/1.2.3/cct-private-1.2.3.jar
[05:57:45]: [DEBUG] /home/tomcat/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar
[05:57:45]: [DEBUG] Execute command :
[05:57:45]: /bin/sh -c /usr/java/jdk1.5.0_14/jre/bin/java -Xmx512m -classpath "/usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/src/main/java":"/usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/src/main/generated":"/usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/src/main/resources":"/usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/${sourceDirectory}":"/usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/ejbModule":"/usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/target/classes":"/home/tomcat/.m2/repository/com/vaadin/vaadin/6.4.6.dev20101005/vaadin-6.4.6.dev20101005.jar":"/home/tomcat/.m2/repository/org/vaadin/henrik/refresher/1.0.0/refresher-1.0.0.jar":"/home/tomcat/.m2/repository/com/google/gwt/gwt-user/2.0.4/gwt-user-2.0.4.jar":"/home/tomcat/.m2/repository/cglib/cglib/2.2/cglib-2.2.jar":"/home/tomcat/.m2/repository/asm/asm/3.1/asm-3.1.jar":"/home/tomcat/.m2/repository/com/tnt/tech-tc/Tech-SharedUtils-Dvn/1.0.16-SNAPSHOT/Tech-SharedUtils-Dvn-1.0.16-SNAPSHOT.jar":"/home/tomcat/.m2/repository/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar":"/home/tomcat/.m2/repository/joda-time/joda-time/1.6/joda-time-1.6.jar":"/home/tomcat/.m2/repository/com/tnt/tech-tc/Tech-Hibernate-Dvn/1.1.3/Tech-Hibernate-Dvn-1.1.3.jar":"/home/tomcat/.m2/repository/com/tnt/tech-tc/Tech-Util-Dvn/2.01.109/Tech-Util-Dvn-2.01.109.jar":"/home/tomcat/.m2/repository/com/tnt/cct/cct-exceptions/1.2.2/cct-exceptions-1.2.2.jar":"/home/tomcat/.m2/repository/com/tnt/cct/cct-public/1.2.3/cct-public-1.2.3.jar":"/home/tomcat/.m2/repository/com/tnt/cct/cct-private/1.2.3/cct-private-1.2.3.jar":"/home/tomcat/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar" com.vaadin.terminal.gwt.widgetsetutils.WidgetSetBuilder com.tnt.vaadin.widgetsets.TNTRefresherApplicationWidgetset
[05:57:45]: [INFO] ** getAvailableWidgetSets **
[05:57:45]: [ERROR] Oct 13, 2010 7:57:45 AM com.vaadin.terminal.gwt.widgetsetutils.ClassPathExplorer getAvailableWidgetSets
[05:57:45]: [ERROR] INFO: Widgetsets found from classpath:
[05:57:45]: [ERROR] com.vaadin.terminal.gwt.DefaultWidgetSet in jar:file:/home/tomcat/.m2/repository/com/vaadin/vaadin/6.4.6.dev20101005/vaadin-6.4.6.dev20101005.jar!/
[05:57:45]: [ERROR] com.tnt.vaadin.widgetsets.TNTRefresherApplicationWidgetset in file:/usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/target/classes
[05:57:45]: [ERROR] org.vaadin.henrik.refresher.RefresherApplicationWidgetset in jar:file:/home/tomcat/.m2/repository/org/vaadin/henrik/refresher/1.0.0/refresher-1.0.0.jar!/
[05:57:45]: [ERROR] src.main.java.com.tnt.vaadin.widgetsets.TNTRefresherApplicationWidgetset in file:/usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db
[05:57:45]: [ERROR]
[05:57:45]: [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-resources-plugin:2.2:testResources' -->
[05:57:45]: [DEBUG] (f) filters = []
[05:57:45]: [DEBUG] (f) outputDirectory = /usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/target/test-classes
[05:57:45]: [DEBUG] (f) project = MavenProject: com.tnt.tech-tc:Tech-VaadinFramework:1.0.0-SNAPSHOT @ /usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/pom.xml
[05:57:45]: [DEBUG] (f) resources = [Resource {targetPath: null, filtering: false, FileSet {directory: /usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/src/test/resources, PatternSet [includes: {}, excludes: {}]}}, Resource {targetPath: null, filtering: false, FileSet {directory: /usr/local/TeamCity/buildAgent2/work/374e58a11dfb42db/src/test/java, PatternSet [includes: {}, excludes: {**/*.java}]}}]
[05:57:45]: [DEBUG] -- end configuration --
Question is though: if we explicitly define in our pom which modules (widgetsets) need to be compiled, why does the plugin still try to scan other directories.
Regards,
Manfred
Manfred Schürhoff: So what we need to do is setup a sourceDirectory variable for our buildplan in TeamCity I guess?
Or is this something we should configure in the pom file for the gwt-maven-plugin or vaadin-maven-plugin? Which one is establishing this classpath.
I have setup an environment variable for our Tech-VaadinFramework build plan:
[indent]sourceDirectory = src/main/java[/indent]
and switched back to version 6.4.4 of Vaadin
This seems to do the trick.
${sourceDirectory} now seems to be substituted by src/main/java. I can't see any references to ${sourceDirectory} in the log any more.
Thanks.
Dear all!
I suffer a bit different kind of problems with Maven + Vaadin integration. In particular for Vaadin v6.4.8, gwt 2.0.4, gwt-maven-plugin v1.3-SNAPSHOT, vaadin-maven-plugin v1.0.1 I result with the message that no widget sets are found:
[INFO] [gwt:resources {execution: default}]
[WARNING] GWT plugin is configured to detect modules, but none where found.
[INFO] [compiler:compile {execution: default-compile}]
[INFO] [vaadin:update-widgetset {execution: default}]
[WARNING] GWT plugin is configured to detect modules, but none were found.
[INFO] No widgetsets to update.
[INFO] To create a widgetset, define a non-existing module in your pom.xml .
[INFO] [resources:testResources {execution: default-testResources}]
When I specify the widget sets manually:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>1.3-SNAPSHOT</version>
<configuration>
<modules>
<module>com.vaadin.terminal.gwt.DefaultWidgetSet</module>
<module>org.vaadin.overlay.OverlaysWidgetset</module>
</modules>
...
I get the following error message (mvn -X install):
[DEBUG] Configuring mojo 'org.codehaus.mojo:gwt-maven-plugin:1.3-SNAPSHOT:resources' -->
[DEBUG] (f) generateDirectory = C:\workspace\chepo\chepo-viewer\target\generated-sources\gwt
[DEBUG] (f) inplace = false
[DEBUG] (f) modules = [com.vaadin.terminal.gwt.DefaultWidgetSet, org.vaadin.overlay.OverlaysWidgetset]
[DEBUG] (f) outputDirectory = C:\workspace\chepo\chepo-viewer\target\classes
[DEBUG] (f) project = MavenProject: org.epo.lifesciences.chepo:chepo-viewer:1.0.0-SNAPSHOT @ C:\workspace\chepo\chepo-viewer\pom.xml
...
[DEBUG] (f) warSourceDirectory = C:\workspace\chepo\chepo-viewer\src\main\webapp
[DEBUG] -- end configuration --
[INFO] [gwt:resources {execution: default}]
[INFO] establishing classpath list (scope = compile)
[DEBUG] candidate artifacts : 0
[DEBUG] GWT SDK execution classpath :
[DEBUG] C:\workspace\chepo\chepo-viewer\src\main\java
[DEBUG] C:\workspace\chepo\chepo-viewer\src\main\resources
[DEBUG] C:\workspace\chepo\chepo-viewer\target\classes
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] GWT Module com.vaadin.terminal.gwt.DefaultWidgetSet not found in project sources or resources.
[INFO] ------------------------------------------------------------------------
[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: GWT Module com.vaadin.terminal.gwt.DefaultWidgetSet not found in project sources or resources.
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
...
Caused by: org.apache.maven.plugin.MojoExecutionException: GWT Module com.vaadin.terminal.gwt.DefaultWidgetSet not found in project sources or resources.
at org.codehaus.mojo.gwt.AbstractGwtModuleMojo.readModule(AbstractGwtModuleMojo.java:184)
at org.codehaus.mojo.gwt.GwtResourcesMojo.execute(GwtResourcesMojo.java:69)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
but when I execute "mvn gwt:compile" everything works as a charm:
[INFO] [gwt:compile {execution: default-cli}]
[INFO] Compiling module com.vaadin.terminal.gwt.DefaultWidgetSet
[INFO] Scanning for additional dependencies: jar:file:/C:/Documents%20and%20Settings/dk83146/.m2/repository/com/vaadin/vaadin/6.4.8/vaadin-6.4.8.jar!/com/vaadin/terminal/gwt/client/WidgetSet.java
[INFO] Computing all possible rebind results for 'com.vaadin.terminal.gwt.client.WidgetMap'
[INFO] Rebinding com.vaadin.terminal.gwt.client.WidgetMap
[INFO] Compiling module org.vaadin.overlay.OverlaysWidgetset
[INFO] Scanning for additional dependencies: jar:file:/C:/Documents%20and%20Settings/dk83146/.m2/repository/com/vaadin/vaadin/6.4.8/vaadin-6.4.8.jar!/com/vaadin/terminal/gwt/client/WidgetSet.java
[INFO] Computing all possible rebind results for 'com.vaadin.terminal.gwt.client.WidgetMap'
[INFO] Rebinding com.vaadin.terminal.gwt.client.WidgetMap
The similar story with "mvn gwt:compile": when no <modules> are defined, it does not find anything; when I define them, I got this error:
[INFO] [vaadin:update-widgetset {execution: default-cli}]
[INFO] Updating widgetset com.vaadin.terminal.gwt.DefaultWidgetSet
[INFO] establishing classpath list (scope = compile)
[ERROR] 23-Nov-2010 11:51:57 com.vaadin.terminal.gwt.widgetsetutils.ClassPathExplorer getAvailableWidgetSets
[ERROR] INFO: Widgetsets found from classpath:
[ERROR] com.vaadin.terminal.gwt.DefaultWidgetSet in jar:file:C:/Documents and Settings/dk83146/.m2/repository/com/vaadin/vaadin/6.4.8/vaadin-6.4.8.jar!/
[ERROR] org.vaadin.overlay.OverlaysWidgetset in jar:file:C:/Documents and Settings/dk83146/.m2/repository/org/vaadin/addons/overlays/0.9.8/overlays-0.9.8.jar!/
[ERROR]
[ERROR] Exception in thread "main" java.io.IOException: The filename, directory name, or volume label syntax is incorrect
[ERROR] at java.io.WinNTFileSystem.canonicalize0(Native Method)
[ERROR] at java.io.Win32FileSystem.canonicalize(Win32FileSystem.java:396)
[ERROR] at java.io.File.getCanonicalPath(File.java:559)
[ERROR] at com.vaadin.terminal.gwt.widgetsetutils.WidgetSetBuilder.updateWidgetSet(WidgetSetBuilder.java:79)
[ERROR] at com.vaadin.terminal.gwt.widgetsetutils.WidgetSetBuilder.main(WidgetSetBuilder.java:52)
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Command [[
C:\Program Files\Java\jdk1.6.0_03\jre\bin\java -Xmx512m -classpath "C:\workspace\chepo\chepo-viewer\src\main\java";"C:\workspace\chepo\chepo-viewer\src\main\resources";"C:\workspace\chepo\chepo-viewer\target\classes";"C:\Documents and Settings\dk83146\.m2\repository\com\vaadin\vaadin\6.4.8\vaadin-6.4.8.jar";"C:\Documents and Settings\dk83146\.m2\repository\org\vaadin\addons\overlays\0.9.8\overlays-0.9.8.jar";"C:\Documents and Settings\dk83146\.m2\repository\com\google\gwt\gwt-user\2.0.4\gwt-user-2.0.4.jar" com.vaadin.terminal.gwt.widgetsetutils.WidgetSetBuilder com.vaadin.terminal.gwt.DefaultWidgetSet
]] failed with status 1
So, question here: Does it look like a bug?
The next problem: I would like to have more fine control over the plugin execution. So I would prefer to have plugins in <pluginManagement> section and execute the re-compilation when necessary. When I do so, "mvn gwt:compile" works with no problem, but "mvn gwt:compile" fails:
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] The plugin 'org.apache.maven.plugins:maven-vaadin-plugin' does not exist or no valid version could be found
Maybe somebody knows, what to trick?
Dmitry Katsubo: When I specify the widget sets manually:
<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>gwt-maven-plugin</artifactId> <version>1.3-SNAPSHOT</version> <configuration> <modules> <module>com.vaadin.terminal.gwt.DefaultWidgetSet</module> <module>org.vaadin.overlay.OverlaysWidgetset</module> </modules> ...
I get the following error message (mvn -X install):
You should not try to compile directly the DefaultWidgetSet nor any widgetsets from add-ons. Instead, you must create your own widgetset file (.gwt.xml) in your own project, in a suitable package in the source tree, which inherits those widgetsets.
The vaadin-maven-plugin exists to update such a widgetset file based on the add-ons in your project, so if you create one from a template and then run "maven vaadin:update-widgetset", the file should get updated. The vaadin-maven-plugin can usually even create a widgetset file if you tell it explicitly which module name to use, but you can also create one from a template.
[INFO] The plugin 'org.apache.maven.plugins:maven-vaadin-plugin' does not exist or no valid version could be found
It looks like you have not specified the plugin correctly in your pom.xml, so I believe Maven assumes it is one of the standard plugins from org.apache.maven.plugins .
See these instructions for using Vaadin add-ons with Maven.
Henri Sara:
You should not try to compile directly the DefaultWidgetSet nor any widgetsets from add-ons. Instead, you must create your own widgetset file (.gwt.xml) in your own project, in a suitable package in the source tree, which inherits those widgetsets.The vaadin-maven-plugin exists to update such a widgetset file based on the add-ons in your project, so if you create one from a template and then run "maven vaadin:update-widgetset", the file should get updated. The vaadin-maven-plugin can usually even create a widgetset file if you tell it explicitly which module name to use, but you can also create one from a template.
See these instructions for using Vaadin add-ons with Maven.
OK, finally I seem to start to understand better what is happening:
- vaadin-maven-plugin updates all found *.gwt.xml files.
- gwt-maven-plugin actually does the rest (and most) of the job.
I have few observations:
- vaadin-maven-plugin changes the sources in source tree. This may affect some procedures on build servers. For example, branching or tagging or releasing may be refused if source code is modified. So the most safe way is to generate widgetset.gwt.xml in project target directory, which inherits com.vaadin.terminal.gwt.DefaultWidgetSet and all application-defined widget sets (from resources) plus all addons' widget sets (from classpath). gwt-maven-plugin should be told to compile this vary widgetset.gwt.xml.
- vaadin-maven-plugin complains "GWT plugin is configured to detect modules, but none were found.". Should be "Vaadin maven plugin is configured to detect modules, but none were found."
I believe, that once widgetset is defined and I am not planning to add more addons, I can disable vaadin-maven-plugin? If yes, why couldn't I leave only gwt-maven-plugin configuration with <modules> defined? Is there anything else happening under the hood?
Henri Sara:
It looks like you have not specified the plugin correctly in your pom.xml, so I believe Maven assumes it is one of the standard plugins from org.apache.maven.plugins .
I just moved <plugins> from <build> to <build><pluginManagement>. If I had a misconfiguration problem, how it worked originally? If you got the minute, may I ask you to do this quick operation (just enclose <plugins> into <pluginManagement>) and try "mvn vaadin:update-widgetset" – will it succeed for you? Thank you in advance.
Dmitry Katsubo: OK, finally I seem to start to understand better what is happening:
- vaadin-maven-plugin updates all found *.gwt.xml files.
- gwt-maven-plugin actually does the rest (and most) of the job.
I have few observations:
- vaadin-maven-plugin changes the sources in source tree. This may affect some procedures on build servers. For example, branching or tagging or releasing may be refused if source code is modified. So the most safe way is to generate widgetset.gwt.xml in project target directory, which inherits com.vaadin.terminal.gwt.DefaultWidgetSet and all application-defined widget sets (from resources) plus all addons' widget sets (from classpath). gwt-maven-plugin should be told to compile this vary widgetset.gwt.xml.
- vaadin-maven-plugin complains "GWT plugin is configured to detect modules, but none were found.". Should be "Vaadin maven plugin is configured to detect modules, but none were found."
I believe, that once widgetset is defined and I am not planning to add more addons, I can disable vaadin-maven-plugin? If yes, why couldn't I leave only gwt-maven-plugin configuration with <modules> defined? Is there anything else happening under the hood?
Yes, normally the vaadin-maven-plugin only needs to be run at development time, after modifying the set of add-ons in the project. However, despite it scanning for widgetsets if not explicitly given, it is reasonably inexpensive to run during every (full) build and should not make modifications if nothing needs to be updated.
If you want it to create the widgetset from scratch, define a module (<modules><module>com.example.test.MyWidgetset</module></modules) in the configuration of vaadin-maven-plugin. For other purposes, I cannot recall whether it reuses some parameters of gwt-maven-plugin or uses its own settings.
You can comment it out from your POM if you want, and either run it when necessary or manage your widgetset file by hand.
It is not necessary to specify the widgetsets (modules section) for gwt-maven-plugin if you want it to automatically look for widgetsets in the project and compile all of them.
As for the error message, I would need to check the code - I believe the plugin might reuse some methods of gwt-maven-plugin when scanning for widgetsets in the project.
Henri Sara:
It looks like you have not specified the plugin correctly in your pom.xml, so I believe Maven assumes it is one of the standard plugins from org.apache.maven.plugins .I just moved <plugins> from <build> to <build><pluginManagement>. If I had a misconfiguration problem, how it worked originally? If you got the minute, may I ask you to do this quick operation (just enclose <plugins> into <pluginManagement>) and try "mvn vaadin:update-widgetset" – will it succeed for you? Thank you in advance.
If I move vaadin-maven-plugin into <pluginManagement>, it works. If I move all the plugins from the archetype into <pluginManagement>, it also works, but the plugins are not automatically connected to build phases - instead, you have to explicitly run e.g. "mvn vaadin:update-widgetset gwt:compile package".
I started with vaadin-archetype-clean, uncommented the relevant sections in pom.xml, added a dependency to an add-on and a module section for vaadin-maven-plugin (to automatically create the widgetset). I then moved all the build plugins under <pluginManagement>.
Did you start with a recent version of one of the Vaadin archetypes (or of the Vaadin Maven wiki page)? Some older versions had errors in the configuration that caused certain settings to be ignored.
Dmitry Katsubo: I believe, that once widgetset is defined and I am not planning to add more addons, I can disable vaadin-maven-plugin? If yes, why couldn't I leave only gwt-maven-plugin configuration with <modules> defined? Is there anything else happening under the hood?
I think, I know why we need to create a dummy widgetset: because <param-name>widgetset</param-name> in web.xml can only contain one widgetset; you can't specify a list of them. That's why once you decided to add an addon, you need to wrap all widget sets into one.
Henri Sara: You can comment it out from your POM if you want, and either run it when necessary or manage your widgetset file by hand.
...
If I move vaadin-maven-plugin into <pluginManagement>, it works. If I move all the plugins from the archetype into <pluginManagement>, it also works, but the plugins are not automatically connected to build phases - instead, you have to explicitly run e.g. "mvn vaadin:update-widgetset gwt:compile package".
That is exactly what I want to achieve: to have a possibility to run the compilation on request.
Henri Sara: I started with vaadin-archetype-clean, uncommented the relevant sections in pom.xml, added a dependency to an add-on and a module section for vaadin-maven-plugin (to automatically create the widgetset). I then moved all the build plugins under <pluginManagement>.
Did you start with a recent version of one of the Vaadin archetypes (or of the Vaadin Maven wiki page)? Some older versions had errors in the configuration that caused certain settings to be ignored.
I have done the following:
mvn archetype:generate -DarchetypeGroupId=com.vaadin -DarchetypeArtifactId=vaadin-archetype-widget -DarchetypeVersion=LATEST -DgroupId=mygroup -DartifactId=tst -Dversion=1.0
It used: vaadin-archetype-widget-1.3.3, Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200), Java version: 1.6.0_03 and generated the POM file which I changed a bit I attached. For this POM "mvn vaadin:update-widgetset" does not work, and "mvn gwt:compile" works fine. I think, this might be also maven configuration problem (I am working under proxy server, this is the only relevant setting in .m2/settings.xml). Could you please attach your pom.xml?
Dmitry Katsubo:
Dmitry Katsubo: I believe, that once widgetset is defined and I am not planning to add more addons, I can disable vaadin-maven-plugin? If yes, why couldn't I leave only gwt-maven-plugin configuration with <modules> defined? Is there anything else happening under the hood?
I think, I know why we need to create a dummy widgetset: because <param-name>widgetset</param-name> in web.xml can only contain one widgetset; you can't specify a list of them. That's why once you decided to add an addon, you need to wrap all widget sets into one.
The actual reasons are quite a bit more complex, related a GWT module having to be compiled in one block - so an application can only use one widgetset at a time. You can think of the widgetsets in add-ons as "fragments" from which you compose your widgetset.
It would be very complex to compile GWT modules for different add-ons separately and make them communicate (requiring explicitly defined javascript level APIs etc.), and there would be significant run-time overhead (both in terms of bandwidth and execution speed) if we would manage to do so. There should be some older forum posts going into more detail about this in case you are interested.
I have done the following:
mvn archetype:generate -DarchetypeGroupId=com.vaadin -DarchetypeArtifactId=vaadin-archetype-widget -DarchetypeVersion=LATEST -DgroupId=mygroup -DartifactId=tst -Dversion=1.0
It used: vaadin-archetype-widget-1.3.3, Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200), Java version: 1.6.0_03 and generated the POM file which I changed a bit I attached. For this POM "mvn vaadin:update-widgetset" does not work, and "mvn gwt:compile" works fine. I think, this might be also maven configuration problem (I am working under proxy server, this is the only relevant setting in .m2/settings.xml). Could you please attach your pom.xml?
Attached in case it helps.
Sorry for a bit of offtopic. I looked around concerning the problem Plugin XXX does not exist or no valid version could be found. This FAQ tells to check proxy settings and do mvn -U ... Didn't help me. The solution is described in maven's documentation: add the following to your settings.xml:
<settings ...>
<pluginGroups>
<pluginGroup>com.vaadin</pluginGroup>
<pluginGroup>org.mortbay.jetty</pluginGroup>
</pluginGroups>
That is why gwt-maven-plugin from org.codehaus.mojo worked out of the box, while vaadin-maven-plugin from com.vaadin failed...
I also think, that switching to jetty-maven-plugin v7.1.x is a good idea (actually here they explain what happened to maven-jetty-plugin), as one don't need to workaround JETTY-680. I also haven't found any replacement for org.mortbay.resource.ResourceCollection, and I believe everything should work by default and dropped this configuration section, because src/main/webapp and ${project.build.directory}/${project.build.finalName} are default paths if one uses jetty:run-exploded.
Is there a way to create a muti module maven project with vaadin, where DOMAIN and SERVICE modules are separated from VAADIN(WEB) module
I am trying to integrate Spring MVC with VAADIN but not sure how to proceed forward. Help is highly appreciated.
Umesh Upadhyay: Is there a way to create a muti module maven project with vaadin, where DOMAIN and SERVICE modules are separated from VAADIN(WEB) module
I am trying to integrate Spring MVC with VAADIN but not sure how to proceed forward. Help is highly appreciated.
It's best if you share you pom.xml configurations for your project and describe how they should look like. If you have project-domain and project-service modules, then there is no place for Vaadin in them. Create new project-web, which depends on two other, and in them module you put dependency to Vaadin.
Hi!
I'm use mavev build in eclipse about 2 years, but yesterday widgetset build was broken!
[INFO] --- gwt-maven-plugin:2.3.0-1:compile (default) @ ArmOGV ---
[INFO] auto discovered modules [com.sitronics.armogv.widgetset.ArmOGVWidgetset]
[INFO] Compiling module com.sitronics.armogv.widgetset.ArmOGVWidgetset
[INFO] [ERROR] Unexpected
[INFO] java.lang.NoSuchFieldError: reportUnusedDeclaredThrownExceptionIncludeDocCommentReference
[INFO] at com.google.gwt.dev.javac.JdtCompiler.getCompilerOptions(JdtCompiler.java:398)
[INFO] at com.google.gwt.dev.javac.JdtCompiler$CompilerImpl.<init>(JdtCompiler.java:228)
[INFO] at com.google.gwt.dev.javac.JdtCompiler.doCompile(JdtCompiler.java:689)
[INFO] at com.google.gwt.dev.javac.CompilationStateBuilder$CompileMoreLater.compile(CompilationStateBuilder.java:215)
[INFO] at com.google.gwt.dev.javac.CompilationStateBuilder.doBuildFrom(CompilationStateBuilder.java:406)
[INFO] at com.google.gwt.dev.javac.CompilationStateBuilder.buildFrom(CompilationStateBuilder.java:299)
[INFO] at com.google.gwt.dev.cfg.ModuleDef.getCompilationState(ModuleDef.java:325)
[INFO] at com.google.gwt.dev.Precompile.precompile(Precompile.java:507)
[INFO] at com.google.gwt.dev.Precompile.precompile(Precompile.java:492)
[INFO] at com.google.gwt.dev.Precompile.precompile(Precompile.java:405)
[INFO] at com.google.gwt.dev.Compiler.run(Compiler.java:215)
[INFO] at com.google.gwt.dev.Compiler.run(Compiler.java:187)
[INFO] at com.google.gwt.dev.Compiler$1.run(Compiler.java:159)
[INFO] at com.google.gwt.dev.CompileTaskRunner.doRun(CompileTaskRunner.java:87)
[INFO] at com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger(CompileTaskRunner.java:81)
[INFO] at com.google.gwt.dev.Compiler.main(Compiler.java:166)
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 16.934s
[INFO] Finished at: Mon Jun 10 16:26:55 YEKST 2013
[INFO] Final Memory: 28M/188M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.codehaus.mojo:gwt-maven-plugin:2.3.0-1:compile (default) on project ArmOGV: Command [[
[ERROR] C:\Program Files\Java\jdk1.6.0_21\jre\bin\java -Xmx512M -Xss1024k -classpath C:\Work\ArmOGV\src\main\java;C:\Work\ArmOGV\src\main\resources;C:\Work\ArmOGV\target\classes;C:\Users\NBochkarev\.m2\repository\net\sourceforge\jtds\jtds\1.2.4\jtds-1.2.4.jar;C:\Users\NBochkarev\.m2\repository\com\thoughtworks\xstream\xstream\1.4.2\xstream-1.4.2.jar;C:\Users\NBochkarev\.m2\repository\xmlpull\xmlpull\1.1.3.1\xmlpull-1.1.3.1.jar;C:\Users\NBochkarev\.m2\repository\xpp3\xpp3_min\1.1.4c\xpp3_min-1.1.4c.jar;C:\Users\NBochkarev\.m2\repository\org\codehaus\groovy\groovy-all\1.7.5\groovy-all-1.7.5.jar;C:\Users\NBochkarev\.m2\repository\net\sf\jasperreports\jasperreports\4.7.1\jasperreports-4.7.1.jar;C:\Users\NBochkarev\.m2\repository\commons-beanutils\commons-beanutils\1.8.0\commons-beanutils-1.8.0.jar;C:\Users\NBochkarev\.m2\repository\commons-collections\commons-collections\2.1\commons-collections-2.1.jar;C:\Users\NBochkarev\.m2\repository\commons-digester\commons-digester\2.1\commons-digester-2.1.jar;C:\Users\NBochkarev\.m2\repository\commons-logging\commons-logging\1.1.1\commons-logging-1.1.1.jar;C:\Users\NBochkarev\.m2\repository\com\lowagie\itext\2.1.7\itext-2.1.7.jar;C:\Users\NBochkarev\.m2\repository\bouncycastle\bcmail-jdk14\138\bcmail-jdk14-138.jar;C:\Users\NBochkarev\.m2\repository\bouncycastle\bcprov-jdk14\138\bcprov-jdk14-138.jar;C:\Users\NBochkarev\.m2\repository\org\bouncycastle\bctsp-jdk14\1.38\bctsp-jdk14-1.38.jar;C:\Users\NBochkarev\.m2\repository\org\bouncycastle\bcprov-jdk14\1.38\bcprov-jdk14-1.38.jar;C:\Users\NBochkarev\.m2\repository\org\bouncycastle\bcmail-jdk14\1.38\bcmail-jdk14-1.38.jar;C:\Users\NBochkarev\.m2\repository\jfree\jcommon\1.0.15\jcommon-1.0.15.jar;C:\Users\NBochkarev\.m2\repository\jfree\jfreechart\1.0.12\jfreechart-1.0.12.jar;C:\Users\NBochkarev\.m2\repository\xml-apis\xml-apis\1.3.02\xml-apis-1.3.02.jar;C:\Users\NBochkarev\.m2\repository\eclipse\jdtcore\3.1.0\jdtcore-3.1.0.jar;C:\Users\NBochkarev\.m2\repository\org\codehaus\castor\castor\1.2\castor-1.2.jar;C:\Users\NBochkarev\.m2\repository\org\apache\poi\poi-ooxml\3.7\poi-ooxml-3.7.jar;C:\Users\NBochkarev\.m2\repository\org\apache\poi\poi\3.7\poi-3.7.jar;C:\Users\NBochkarev\.m2\repository\org\apache\poi\poi-ooxml-schemas\3.7\poi-ooxml-schemas-3.7.jar;C:\Users\NBochkarev\.m2\repository\org\apache\xmlbeans\xmlbeans\2.3.0\xmlbeans-2.3.0.jar;C:\Users\NBochkarev\.m2\repository\stax\stax-api\1.0.1\stax-api-1.0.1.jar;C:\Users\NBochkarev\.m2\repository\org\apache\geronimo\specs\geronimo-stax-api_1.0_spec\1.0\geronimo-stax-api_1.0_spec-1.0.jar;C:\Users\NBochkarev\.m2\repository\dom4j\dom4j\1.6.1\dom4j-1.6.1.jar;C:\Users\NBochkarev\.m2\repository\org\codehaus\jackson\jackson-core-asl\1.9.4\jackson-core-asl-1.9.4.jar;C:\Users\NBochkarev\.m2\repository\org\codehaus\jackson\jackson-mapper-asl\1.9.4\jackson-mapper-asl-1.9.4.jar;C:\Users\NBochkarev\.m2\repository\com\vaadin\vaadin\6.8.6\vaadin-6.8.6.jar;C:\Users\NBochkarev\.m2\repository\org\vaadin\addons\activelink\1.0\activelink-1.0.jar;C:\Users\NBochkarev\.m2\repository\org\vaadin\addons\appletintegration\1.2.9\appletintegration-1.2.9.jar;C:\Users\NBochkarev\.m2\repository\ch\qos\cal10n\cal10n-api\0.7.4\cal10n-api-0.7.4.jar;C:\Users\NBochkarev\.m2\repository\com\google\gwt\gwt-servlet\2.3.0\gwt-servlet-2.3.0.jar;C:\Users\NBochkarev\.m2\repository\com\google\gwt\gwt-user\2.3.0\gwt-user-2.3.0.jar;C:\Users\NBochkarev\.m2\repository\com\sun\xml\ws\webservices-rt\1.4\webservices-rt-1.4.jar;C:\Users\NBochkarev\.m2\repository\javax\xml\webservices-api\1.4\webservices-api-1.4.jar;C:\Users\NBochkarev\.m2\repository\javax\activation\activation\1.1\activation-1.1.jar;C:\Users\NBochkarev\.m2\repository\commons-httpclient\commons-httpclient\3.1\commons-httpclient-3.1.jar;C:\Users\NBochkarev\.m2\repository\commons-codec\commons-codec\1.2\commons-codec-1.2.jar;C:\Users\NBochkarev\.m2\repository\org\apache\httpcomponents\httpclient\4.1-beta1\httpclient-4.1-beta1.jar;C:\Users\NBochkarev\.m2\repository\org\apache\httpcomponents\httpcore\4.1\httpcore-4.1.jar;C:\Users\NBochkarev\.m2\repository\org\apache\axis\axis\1.4\axis-1.4.jar;C:\Users\NBochkarev\.m2\repository\org\apache\axis\axis-jaxrpc\1.4\axis-jaxrpc-1.4.jar;C:\Users\NBochkarev\.m2\repository\commons-discovery\commons-discovery\0.5\commons-discovery-0.5.jar;C:\Users\NBochkarev\.m2\repository\wsdl4j\wsdl4j\1.6.2\wsdl4j-1.6.2.jar;C:\Users\NBochkarev\.m2\repository\com\sitronics\LoginWidget\1.1.1\LoginWidget-1.1.1.jar;C:\Users\NBochkarev\.m2\repository\commons-lang\commons-lang\2.4\commons-lang-2.4.jar;C:\Users\NBochkarev\.m2\repository\org\slf4j\slf4j-ext\1.6.4\slf4j-ext-1.6.4.jar;C:\Users\NBochkarev\.m2\repository\ch\qos\logback\logback-classic\1.0.4\logback-classic-1.0.4.jar;C:\Users\NBochkarev\.m2\repository\ch\qos\logback\logback-core\1.0.4\logback-core-1.0.4.jar;C:\Users\NBochkarev\.m2\repository\org\slf4j\slf4j-api\1.6.4\slf4j-api-1.6.4.jar;C:\Work\ArmOGV\src\main\webapp\WEB-INF\lib\sqljdbc4.jar;C:\Work\ArmOGV\src\main\webapp\WEB-INF\lib\ws_framework-1.0.0.jar;C:\Work\ArmOGV\src\main\webapp\WEB-INF\lib\ws_resourcestore-1.0.0.jar;C:\Work\ArmOGV\src\main\webapp\WEB-INF\lib\ws_common-1.0.0.jar;C:\Work\ArmOGV\src\main\webapp\WEB-INF\lib\ws_resourcebundle-1.0.0.jar;C:\Work\ArmOGV\src\main\webapp\WEB-INF\lib\tpt-core.jar;C:\Users\NBochkarev\.m2\repository\net\sf\ehcache\ehcache\1.2.2\ehcache-1.2.2.jar;C:\Users\NBochkarev\.m2\repository\org\hibernate\hibernate\3.2.0.cr3\hibernate-3.2.0.cr3.jar;C:\Users\NBochkarev\.m2\repository\cglib\cglib\2.1_3\cglib-2.1_3.jar;C:\Users\NBochkarev\.m2\repository\asm\asm\1.5.3\asm-1.5.3.jar;C:\Users\NBochkarev\.m2\repository\asm\asm-attrs\1.5.3\asm-attrs-1.5.3.jar;C:\Users\NBochkarev\.m2\repository\antlr\antlr\2.7.6\antlr-2.7.6.jar;C:\Users\NBochkarev\.m2\repository\net\sf\hibernate\hibernate\2.1.8\hibernate-2.1.8.jar;C:\Users\NBochkarev\.m2\repository\javax\servlet\servlet-api\2.4\servlet-api-2.4.jar;C:\Users\NBochkarev\.m2\repository\org\vaadin\addons\easyuploads\0.5.1\easyuploads-0.5.1.jar;C:\Users\NBochkarev\.m2\repository\com\google\gwt\gwt-user\2.3.0\gwt-user-2.3.0.jar;C:\Users\NBochkarev\.m2\repository\javax\validation\validation-api\1.0.0.GA\validation-api-1.0.0.GA.jar;C:\Users\NBochkarev\.m2\repository\javax\validation\validation-api\1.0.0.GA\validation-api-1.0.0.GA-sources.jar;C:\Users\NBochkarev\.m2\repository\com\google\gwt\gwt-dev\2.3.0\gwt-dev-2.3.0.jar com.google.gwt.dev.Compiler -gen C:\Work\ArmOGV\target\.generated -logLevel INFO -style OBF -war C:\Work\ArmOGV\target\ArmOGV\VAADIN\widgetsets -localWorkers 8 com.sitronics.armogv.widgetset.ArmOGVWidgetset
[ERROR] ]] failed with status 1
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
here my pom:
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<vaadin.version>6.8.6</vaadin.version>
<gwt.version>2.3.0</gwt.version>
<gwt.plugin.version>2.3.0</gwt.plugin.version>
</properties>
...
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<!-- Version 2.1.0-1 works at least with Vaadin 6.5 -->
<version>2.3.0-1</version>
<configuration>
<!-- if you don't specify any modules, the plugin will find them -->
<!--modules> .. </modules -->
<webappDirectory>${project.build.directory}/${project.build.finalName}/VAADIN/widgetsets</webappDirectory>
<extraJvmArgs>-Xmx512M -Xss1024k</extraJvmArgs>
<runTarget>clean</runTarget>
<hostedWebapp>${project.build.directory}/${project.build.finalName}</hostedWebapp>
<noServer>true</noServer>
<port>8080</port>
<soyc>false</soyc>
</configuration>
<executions>
<execution>
<goals>
<goal>resources</goal>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- Updates Vaadin 6.2+ widgetset definitions based on project dependencies -->
<plugin>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-maven-plugin</artifactId>
<version>1.0.1</version>
<executions>
<execution>
<configuration>
</configuration>
<goals>
<goal>update-widgetset</goal>
</goals>
</execution>
</executions>
</plugin>
run command:
mvn vaadin:update-widgetset install
What the problem?
I'm don't change anything...
Have you tried cleaning the project?
Has the JDK version on the computer been changed?
Most likely this is a classpath issue with two incompatible versions of some library on the classpath - probably GWT libraries and Tomcat.
You could try to add <gwtSdkFirstInClasspath>true</gwtSdkFirstInClasspath> to your GWT plugin configuration and see if it helps.
Henri Sara: You could try to add <gwtSdkFirstInClasspath>true</gwtSdkFirstInClasspath> to your GWT plugin configuration and see if it helps.
Thank YOU very much!
<gwtSdkFirstInClasspath>true</gwtSdkFirstInClasspath>
realy help me!
p.s. yes, before it clean the project, JDK not change..