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.
vaadin:compile crash with too long pathname
Hello,
I think this is a know issue of the gwt plugin/compiler ... see https://github.com/gwt-maven-plugin/gwt-maven-plugin/issues/113.
00:13:52.002 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.vaadin:vaadin-maven-plugin:7.6.6:compile (default) on project reorder-system: Failed to execute command line : 00:13:52.004 [-Xmx512M, -Xss10M, -classpath, D:\applications\prg\jenkinsSlave1\workspace\job-dsl\feature-PRO-3994_Spring4_Migration-commit\reorder-system\reorder-system\target\classes;D:\applications\prg\jenkinsSlave1\workspace\job-dsl\feature-PRO-3994_Spring4_Migration-commit\reorder-system\reorder-system\src\main\java;D:\applications\prg\jenkinsSlave1\workspace\job-dsl\feature-PRO-3994_Spring4_Migration-commit\reorder-system\reorder-system\target\generated- <... many many entries ...>
, com.google.gwt.dev.Compiler, -logLevel, INFO, -style, OBF, -war, D:\applications\prg\jenkinsSlave1\workspace\job-dsl\feature-PRO-3994_Spring4_Migration-commit\reorder-system\reorder-system\src\main\webapp\VAADIN\widgetsets, -localWorkers, 4, -strict, -XfragmentCount, -1, -optimize, 9, -gen, D:\applications\prg\jenkinsSlave1\workspace\job-dsl\feature-PRO-3994_Spring4_Migration-commit\reorder-system\reorder-system\target\.generated, com.siemens.spice.reorder.ReorderWidgetSet]
00:13:52.005 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212) 00:13:52.005 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) 00:13:52.005 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) 00:13:52.005 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) 00:13:52.005 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) 00:13:52.005 at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) 00:13:52.005 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) 00:13:52.005 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307) 00:13:52.005 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193) 00:13:52.005 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106) 00:13:52.005 at org.jvnet.hudson.maven3.launcher.Maven32Launcher.main(Maven32Launcher.java:132) 00:13:52.005 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 00:13:52.005 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 00:13:52.005 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 00:13:52.005 at java.lang.reflect.Method.invoke(Method.java:498) 00:13:52.005 at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:330) 00:13:52.005 at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:238) 00:13:52.005 at jenkins.maven3.agent.Maven32Main.launch(Maven32Main.java:186) 00:13:52.005 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 00:13:52.005 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 00:13:52.005 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 00:13:52.005 at java.lang.reflect.Method.invoke(Method.java:498) 00:13:52.005 at hudson.maven.Maven3Builder.call(Maven3Builder.java:136) 00:13:52.005 at hudson.maven.Maven3Builder.call(Maven3Builder.java:71) 00:13:52.005 at hudson.remoting.UserRequest.perform(UserRequest.java:153) 00:13:52.005 at hudson.remoting.UserRequest.perform(UserRequest.java:50) 00:13:52.005 at hudson.remoting.Request$2.run(Request.java:332) 00:13:52.005 at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) 00:13:52.005 at java.util.concurrent.FutureTask.run(FutureTask.java:266) 00:13:52.005 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 00:13:52.005 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 00:13:52.005 at java.lang.Thread.run(Thread.java:745) 00:13:52.005 Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to execute command line :
.... again the whole thing ...
00:13:52.008 at org.codehaus.mojo.gwt.shell.AbstractGwtShellMojo$JavaCommand.execute(AbstractGwtShellMojo.java:512) 00:13:52.008 at org.codehaus.mojo.gwt.shell.CompileMojo.compile(CompileMojo.java:366) 00:13:52.008 at org.codehaus.mojo.gwt.shell.CompileMojo.doExecute(CompileMojo.java:281) 00:13:52.008 at org.codehaus.mojo.gwt.shell.AbstractGwtShellMojo.execute(AbstractGwtShellMojo.java:172) 00:13:52.008 at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) 00:13:52.008 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207) 00:13:52.008 ... 31 more 00:13:52.008 Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error while executing process. 00:13:52.008 at org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:656) 00:13:52.008 at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:144) 00:13:52.008 at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:107) 00:13:52.008 at org.codehaus.mojo.gwt.shell.AbstractGwtShellMojo$JavaCommand.execute(AbstractGwtShellMojo.java:492) 00:13:52.008 ... 36 more 00:13:52.008 Caused by: java.io.IOException: Cannot run program "D:\applications\prg\java\jdk8x64\jre\bin\java": CreateProcess error=206, Der Dateiname oder die Erweiterung ist zu lang 00:13:52.008 at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048) 00:13:52.008 at java.lang.Runtime.exec(Runtime.java:620) 00:13:52.008 at java.lang.Runtime.exec(Runtime.java:528) 00:13:52.008 at org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:636) 00:13:52.008 ... 39 more 00:13:52.008 Caused by: java.io.IOException: CreateProcess error=206, Der Dateiname oder die Erweiterung ist zu lang 00:13:52.008 at java.lang.ProcessImpl.create(Native Method) 00:13:52.008 at java.lang.ProcessImpl.<init>(ProcessImpl.java:386) 00:13:52.008 at java.lang.ProcessImpl.start(ProcessImpl.java:137) 00:13:52.008 at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029) 00:13:52.008 ... 42 more 00:13:52.008 [ERROR] 00:13:52.008 [ERROR] Re-run Maven using the -X switch to enable full debug logging. 00:13:52.008 [ERROR] 00:13:52.009 [ERROR] For more information about the errors and possible solutions, please read the following articles: 00:13:52.009 [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException 00:13:52.021 channel stopped
Is there a solution for that. Currently we are at Siemens running in a kind of "blocker situation" because we can't build / deploy our applications (jenkins). The dependencies are growing everywhere :)
Any ideas?
Kind Regards
Andreas
When we faced that problem we ended up moving widgetset and theme in separate projects
HTH
Marco
With current Vaadin versions you could also just not compile the widgetset, and let the maven plugin fetch it from Vaadin's CDN.
<configuration>
<widgetsetMode>fetch</widgetsetMode>
</configuration>
We do that on our developer machines (our build server runs on Linux, which doesn't have this problem).
If that's not an option Marco Collovati's suggestion is the way to go.
Thanks for the hints.
We are still using 7.6.6. CDN is not yet possible :) Also we are using some handmande (none official) addons, so I'm not sure about that with CDN.
The idea with a widgetset for the whole project is already on the table ...
Yeah, if you're using your own addons, then the CDN wouldn't work for you anyway.
-Olli
I think about a fix in the gwt/vaadin maven plugin ... if the gwt-compiler java process is forked the classpath should not be transported via commandline parameter. A bootstrap mechanism like for maven-surefire would be bullet-proofed.
So passing classpath as environment variable CLASSPATH to org.codehaus.plexus.util.cli.Commandline instead of "-classpath" argument should work?
Is there a archetype or something to create a widgetset project? I guess such a project is a normal jar artifact.