GWT/Maven development cycle takes much too long

[Magnus]

Hello,

after moving my projects to Maven, I am at a point where everything works again, with the help of the people in this group.

However, when concentrating on the actual work again, I notice that the development cycle I have started with takes too long, so that I cannot be productive in any way.

I am sure that it can be improved somehow, but how?

Here is the simplified scenario:

There are two Maven projects:

• my-lib:
  a code library for any code (server-side and GWT-aware) that may be used by more than one application
• my-app:
  an actual GWT application that uses the library

The library project is built with the install goal (mvn install), so its jar file is stored in the local repository. This jar file in the repository is gripped by the application project, which has a corresponding dependency in its pom.xml file.

Both projects are imported into eclipse.

When everything is up-to-date, I can select "Debug as GWT Development Mode with Jetty", run and debug the application without any problems.

So far so good. Now it comes:

Sometimes I see a problem in the library code while debugging. Then, I want to stop debugging and edit the code. But then, the code is not editable, because eclipse is showing the source code included in the library jar file, not the original code from the library's Maven project. You can see that eclipse shows the source code labeled with a *.class file instead of a *.java file:

So, I cannot edit the code immediately. I have to open the original file and edit the code there.

But what after having done this?

The application project cannot "see" the changed code, because it only sees the jar file with the unchanged code in the local repository.

It also doesn't seem that eclipse realizes this and does all the necessary steps automatically: When I start a new debugging session after having changed the code, I see the old code in the class file, as described above.

So the only thing I can do right now is go to the command line an do this:

• update the library and update the local repository:
  mvn package install
  
• update the application, so that it fetches the new library jar file from the repository into its WEB-INF/lib directory
  mvn package

Especially the second step takes very long, since it will compile the permutations.

After that I have to do a "Refresh" inside eclipse for both projects.

Then, finally, I can start a new debugging session again.

But wait: What is it that I wanted to do when coming back here? #-)

The cycle described above takes about 20 minutes.

What am I doing wrong?

Thanks
Magnus

[Kirill Prazdnikov]

First of all I recommend remove all permutations.
This is very easy, add this to module.gwt.xml:
<set-property name="user.agent" value="safari"/>
This will use the only perm for all browsers. That are not needed actually.

Then you can omit GWT compilation at all before you are going to start super-dev-mode because codeserver itself will also compile everything again.
And finally you can edit and instant rebuild in superdevmode (it takes few seconds).

[Magnus]

Hello Kirill,

thank you for your recommendations. I will remove all permutations as you said and see how it improves work.

But I believe that the real cause of the problem is another one:

You did not address the special problem with the two maven projects:

Debug the app, then see a problem in the code of the library used by the app, correct this code and restart debugging the app.

I also have posted what happens when I omit GWT compilation: I see old library code when debugging the application...

Magnus

[Boris Brudnoy]

On Tue, Apr 18, 2017 at 12:03 PM Magnus <alpine...@gmail.com> wrote:

Hello,

after moving my projects to Maven, I am at a point where everything works again, with the help of the people in this group.

However, when concentrating on the actual work again, I notice that the development cycle I have started with takes too long, so that I cannot be productive in any way.

I am sure that it can be improved somehow, but how?

Here is the simplified scenario:

There are two Maven projects:

• my-lib:
  a code library for any code (server-side and GWT-aware) that may be used by more than one application
• my-app:
  an actual GWT application that uses the library

The library project is built with the install goal (mvn install), so its jar file is stored in the local repository. This jar file in the repository is gripped by the application project, which has a corresponding dependency in its pom.xml file.

Both projects are imported into eclipse.

When everything is up-to-date, I can select "Debug as GWT Development Mode with Jetty", run and debug the application without any problems.

So far so good. Now it comes:

Sometimes I see a problem in the library code while debugging. Then, I want to stop debugging and edit the code. But then, the code is not editable, because eclipse is showing the source code included in the library jar file, not the original code from the library's Maven project. You can see that eclipse shows the source code labeled with a *.class file instead of a *.java file:

So, I cannot edit the code immediately. I have to open the original file and edit the code there.

But what after having done this?

In your Project Properties --> Maven, is the 'Resolve dependencies from Workspace projects' checkbox checked? That's supposed to incorporate the actual project code of your library into the project that depends on that library, assuming both are in the same workspace.

The application project cannot "see" the changed code, because it only sees the jar file with the unchanged code in the local repository.

It also doesn't seem that eclipse realizes this and does all the necessary steps automatically: When I start a new debugging session after having changed the code, I see the old code in the class file, as described above.

So the only thing I can do right now is go to the command line an do this:

• update the library and update the local repository:
  mvn package install
  
• update the application, so that it fetches the new library jar file from the repository into its WEB-INF/lib directory
  mvn package

Especially the second step takes very long, since it will compile the permutations.

After that I have to do a "Refresh" inside eclipse for both projects.

Then, finally, I can start a new debugging session again.

But wait: What is it that I wanted to do when coming back here? #-)

The cycle described above takes about 20 minutes.

What am I doing wrong?

Thanks
Magnus

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

--

BORIS BRUDNOY

Web Application Developer, Java/GWT Enthusiast (LinkedIn)

[Pavlo Iatsiuk]

Hello,

I have similar projects structure and do next:

 - start my-app and code server for my-app. In my case I use jetty maven plugin to start application and gwt plugin to start code server

 - do your changes in my-lib and mvn install after that. It should be very fast because there is just plain java compilation.  

 - restart just code server for code server for my-app. I use property <gwt.codeServer.precompile>false</gwt.codeServer.precompile> as result code server start pretty fast too.

 - reload page in browser

[Kirill Prazdnikov]

You did not address the special problem with the two maven projects:

Yes, sorry about that I'm not maven expert, I don`t know details. 

We use IDEA to start superdevmode and use maven modules list in parent pom so that there is no need to mvn-install all the modules and IDEA maven plugin build classpath including all the modules path for codeserver.

<modules>

    <module>lib</module>

    <module>app</module>

</modules>

[Frank]

I use the GWT Eclipse plugin from Brandon Donnelson (not the one from Google) for launching SuperDev.
I have about 10 seperate library projects and I can make changes in those without and just refresh the browser and just wait about 3 seconds to see the changes.

https://github.com/gwt-plugins/gwt-eclipse-plugin

I just watched his YouTube channel for how to set it up. Was not that much work : https://www.youtube.com/watch?v=DU7ZQVLR5Zo&list=PLBbgqtDgdc_TqzA-qXrjgTFMC_6DKAQyT

We don't use maven but ANT for building the final war. We can also launch SuperDevMode using ANT but had the same issue you described. So using the eclipse plugin has brought a massive advantage.

[Magnus]

Hi Pavlo!

I would like to do it the same way. But what exactly are the steps you describe? Do you execute them on the commandline with maven commands or in eclipse?

I really would like to do it the same way!

Magnus 

[Thomas Broyer]

Passing property gwt.compiler.skip=true will skip GWT compilation.

 

After that I have to do a "Refresh" inside eclipse for both projects.

Then, finally, I can start a new debugging session again.

But wait: What is it that I wanted to do when coming back here? #-)

The cycle described above takes about 20 minutes.

What am I doing wrong?

As I already said several times, I strongly suggest you use a reactor (multi-module build) so that you don't need to "mvn install" the library before you can use it; at least when using "mvn gwt:devmode" and/or "mvn gwt:codeserver". (to answer your questions from another thread, use whatever you want as groupId/artifactId/version for the root/reactor module, it really doesn't matter if you're only using it for development; it only matters if you "mvn install" and/or "mvn deploy" it)

I have no idea why Eclipse has errors when importing/updating the "app" project, and I hope you'll eventually find out and find a fix/workaround, but I would personally focus on getting things working outside the IDE (with Maven only), and then only getting them working with/in the IDE. Then you can possibly use the GWT Eclipse Plugin to run your app instead of Maven.

That being said, you can have things working right now, by (manually) tweaking the classpath for the dev mode, to include the "lib" project *and* source folders.

[Magnus]

Hi Thomas,

I already have started to play with a reactor. Below is my top-level pom.xml. But where to go from here?

What are the mvn commands to build everything on the top-level? If "mvn install" isn't needed anymore, how does the app project see the library?

This is also the point with the development cycle: When debugging, eclipse doesn't "see" the changed library source code, because it fetches the library source code from the jar file in its own target folder. And this jar file is updated only by "mvn install" at the app project. Wouldn't it be better for developing if the original library code was used instead? Could it be that this is the core of the problem?

Thanks
Magnus

-----

pom.xml:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

 <modelVersion>4.0.0</modelVersion>

 <groupId>msm</groupId>

 <artifactId>msm</artifactId>

 <version>1.0</version>

 <packaging>pom</packaging>

  <packaging>pom</packaging>

  <modules>

   <module>msm-lib-acs</module>

   <module>msm-apl-mcs</module>

  </modules>

</project>

[Thomas Broyer]

On Friday, April 21, 2017 at 5:58:58 PM UTC+2, Magnus wrote:

Hi Thomas,

I already have started to play with a reactor. Below is my top-level pom.xml. But where to go from here?

What are the mvn commands to build everything on the top-level? If "mvn install" isn't needed anymore, how does the app project see the library?

Because msm-apl-mcs has a dependency on msm-lib-acs, Maven will always build the latter before the former (when executed on the whole reactor).

If the "package" phase is part of the build (e.g. you execute "mvn package" or "mvn verify" for example), then the JAR for msm-lib-acs will be "attached" to the project and will be used by "msm-apl-mcs". Otherwise (e.g. you use "mvn test" or "mvn gwt:devmode"), "msm-lib-acs" will have no known attached artifact, so "msm-apl-mcs" will have to use something else (this is why I recommend never using phases before "package" when invoking Maven in reactors; the "gwt:devmode" goal has special handling for reactor builds, contrary to the "gwt:run" from the MojoHaus' plugin); and if msm-lib-acs has packaging 'jar' and the dependency is on the jar type with no classifier, then it'll be its target/classes folder, and otherwise it'll be nothing (IIRC).

So, "mvn package" should Just Work™ (package the lib, then package the app using the lib's jar).

"mvn gwt:devmode" and "mvn gwt:codeserver" should work without too much configuration (configure warDir/launcherDir, possibly projects/modules)

 

This is also the point with the development cycle: When debugging, eclipse doesn't "see" the changed library source code, because it fetches the library source code from the jar file in its own target folder.

Actually the one from your local repository (~/.m2/repository/), not directly the one from the target/ folder.

 

And this jar file is updated only by "mvn install" at the app project. Wouldn't it be better for developing if the original library code was used instead? Could it be that this is the core of the problem?

Yes, it is.

And the problem is that Eclipse errors when importing your app project when using the default configuration for resolving dependencies from the workspace; which is why you turned that setting off.

If you figure out how to get this working, then it should (hopefully work) the same with or without a reactor.

But with a reactor at least you can have things working with "mvn gwt:devmode" and/or "mvn gwt:codeserver" (and your developers could then possibly switch to other IDEs if you allow them to: NetBeans, IntelliJ IDEA, or even VSCode)

Tweaking the classpath for the DevMode launcher in Eclipse to include the lib's project and source folders could also be a temporary workaround while you figure things out on the Eclipse project import front.

[Magnus]

So, "mvn package" should Just Work™ (package the lib, then package the app using the lib's jar).

Yes, works!

 

"mvn gwt:devmode" and "mvn gwt:codeserver" should work without too much configuration (configure warDir/launcherDir, possibly projects/modules)

Actually, it gives an error (see below):

Could not find goal 'devmode' in plugin org.codehaus.mojo:gwt-maven-plugin:2.8.0 among available goals...

I believe I have to extend the minimal top-level pom.xml, but how?

And I'd like to leave the pom.xml in the sub folders as is, because they are working for their own... Is this possible?

 

This is also the point with the development cycle: When debugging, eclipse doesn't "see" the changed library source code, because it fetches the library source code from the jar file in its own target folder.

Actually the one from your local repository (~/.m2/repository/), not directly the one from the target/ folder.

This is an important point! If the app used the library jar from the repository and not from its own target directory, there would be no need to "mvn package" the app and this takes most of the time...

 

Wouldn't it be better for developing if the original library code was used instead? Could it be that this is the core of the problem?

 

And the problem is that Eclipse errors when importing your app project when using the default configuration for resolving dependencies from the workspace; which is why you turned that setting off.

If you figure out how to get this working, then it should (hopefully work) the same with or without a reactor.

I can enable it for the lib project without problems. But as soon as I enable it for the app project, the error reappears.

It's hard to figure it out when even the experts in this group have no idea. But I see that this is an essential point, so I have documented the error as detailed as possible again (see below). I hope there will be a solution...

 

Thanks

Magnus 

Maven error when executing "mvn gwt:devmode" at the top-level:

[INFO] Reactor Build Order:

[INFO] 

[INFO] msm-lib-acs

[INFO] msm.app.bcs.Application

[INFO] msm

[INFO] ------------------------------------------------------------------------

[INFO] Reactor Summary:

[INFO] 

[INFO] msm-lib-acs ....................................... SKIPPED

[INFO] msm.app.bcs.Application ........................... SKIPPED

[INFO] msm ............................................... SKIPPED

[INFO] ------------------------------------------------------------------------

[INFO] BUILD FAILURE

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 2.603s

[INFO] Finished at: Fri Apr 21 19:13:32 CEST 2017

[INFO] Final Memory: 10M/241M

[INFO] ------------------------------------------------------------------------

[ERROR] Could not find goal 'devmode' in plugin org.codehaus.mojo:gwt-maven-plugin:2.8.0 among available goals clean, compile, compile-report, css, debug, eclipse, eclipseTest, generateAsync, help, i18n, mergewebxml, resources, run, run-codeserver, source-jar, test -> [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/MojoNotFoundException

 

Error in the application project's pom.xml when "resolve dependencies" is enabled:

The pom.xml has an error marker at the packaging tag:

The error behind this error marker is this:

Failed to copy file for artifact [msm.lib.acs:msm-lib-acs:jar:1.0-SNAPSHOT:compile] (org.apache.maven.plugins:maven-war-plugin:2.2:war:default-war:package)

org.apache.maven.plugin.MojoExecutionException: Failed to copy file for artifact [msm.lib.acs:msm-lib-acs:jar:1.0-SNAPSHOT:compile]

at org.apache.maven.plugin.war.packaging.ArtifactsPackagingTask.performPackaging(ArtifactsPackagingTask.java:131)

at org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.handleArtifacts(WarProjectPackagingTask.java:190)

at org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.performPackaging(WarProjectPackagingTask.java:109)

at org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:472)

at org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:404)

at org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:215)

at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:177)

at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)

at org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:331)

at org.eclipse.m2e.core.internal.embedder.MavenImpl$11.call(MavenImpl.java:1362)

at org.eclipse.m2e.core.internal.embedder.MavenImpl$11.call(MavenImpl.java:1)

at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:176)

at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:112)

at org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:1360)

at org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant.build(MojoExecutionBuildParticipant.java:52)

at org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.build(MavenBuilderImpl.java:137)

at org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:172)

at org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:1)

at org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod$1$1.call(MavenBuilder.java:115)

at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:176)

at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:112)

at org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod$1.call(MavenBuilder.java:105)

at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:176)

at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:151)

at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:99)

at org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:86)

at org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:200)

at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:735)

at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)

at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)

at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)

at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:301)

at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)

at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:304)

at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:360)

at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:383)

at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144)

at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:235)

at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

Caused by: java.io.FileNotFoundException: /home/wagner/dvl/prj/msm/msm-lib-acs/target/classes (Is a directory)

at java.io.FileInputStream.open0(Native Method)

at java.io.FileInputStream.open(FileInputStream.java:195)

at java.io.FileInputStream.<init>(FileInputStream.java:138)

at org.codehaus.plexus.util.io.FileInputStreamFacade.getInputStream(FileInputStreamFacade.java:36)

at org.codehaus.plexus.util.FileUtils.copyStreamToFile(FileUtils.java:1141)

at org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:1048)

at org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFile(AbstractWarPackagingTask.java:293)

at org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask$1.registered(AbstractWarPackagingTask.java:150)

at org.apache.maven.plugin.war.util.WebappStructure.registerFile(WebappStructure.java:211)

at org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFile(AbstractWarPackagingTask.java:145)

at org.apache.maven.plugin.war.packaging.ArtifactsPackagingTask.performPackaging(ArtifactsPackagingTask.java:106)

... 38 more

[Juan Pablo Gardella]

I suggest to make a POC using https://github.com/tbroyer/gwt-maven-archetypes/ archetype, using modular-webapp.

[Thomas Broyer]

On Friday, April 21, 2017 at 7:38:37 PM UTC+2, Magnus wrote:

So, "mvn package" should Just Work™ (package the lib, then package the app using the lib's jar).

Yes, works!

 

"mvn gwt:devmode" and "mvn gwt:codeserver" should work without too much configuration (configure warDir/launcherDir, possibly projects/modules)

Actually, it gives an error (see below):

Could not find goal 'devmode' in plugin org.codehaus.mojo:gwt-maven-plugin:2.8.0 among available goals...

I believe I have to extend the minimal top-level pom.xml, but how?

And I'd like to leave the pom.xml in the sub folders as is, because they are working for their own... Is this possible?

As I said, the MojoHaus plugin doesn't work well in reactor builds, it simply hasn't been designed to support them.

The net.ltgt.gwt.maven:gwt-maven-plugin (where the devmode and codeserver goals can be found) has been specifically designed for that.

You can probably mix both plugins (i.e. keep the MojoHaus plugin in the submodules for the build, use the net.ltgt.gwt.maven plugin in the root module only for the devmode/codeserver goals) with a bit more configuration (explicit projects and modules, rather than automatic discovery in submodules).

 

 

This is also the point with the development cycle: When debugging, eclipse doesn't "see" the changed library source code, because it fetches the library source code from the jar file in its own target folder.

Actually the one from your local repository (~/.m2/repository/), not directly the one from the target/ folder.

This is an important point! If the app used the library jar from the repository and not from its own target directory, there would be no need to "mvn package" the app and this takes most of the time...

 

Wouldn't it be better for developing if the original library code was used instead? Could it be that this is the core of the problem?

 

And the problem is that Eclipse errors when importing your app project when using the default configuration for resolving dependencies from the workspace; which is why you turned that setting off.

If you figure out how to get this working, then it should (hopefully work) the same with or without a reactor.

I can enable it for the lib project without problems. But as soon as I enable it for the app project, the error reappears.

It's hard to figure it out when even the experts in this group have no idea. But I see that this is an essential point, so I have documented the error as detailed as possible again (see below). I hope there will be a solution...

It really doesn't look like this is specific to GWT; so if I were you I'd ask on the M2Eclipse mailing list (if any) and/or on StackOverflow. You (a priori) need to find Eclipse/M2Eclipse experts, not GWT experts that (possibly) happen to use Eclipse/M2Eclipse. It looks really strange to me that Eclipse attemps to package the project on import, and this is the crux of the problem (it is the maven-war-plugin that's failing).

It would probably help to know the exact version of Eclipse (and M2Eclipse, WTP, and m2e-wtp plugins) you're using, and any other plugin you have installed that could trigger that behavior (reproducing in an out-of-the-box Eclipse install would allow excluding bad plugin interactions).

Having a small (as small as possible, just a jar and war projects, no external dependencies besides javax.servlet) project available (e.g. on GitHub) would also help, so that others could try to reproduce the problem from the same sources.

(also, maven-war-plugin 2.2 is 5 years old already, maybe try using a more recent version? if you don't explicitly specify a version, try a newer Maven version; though the one Eclipse uses is likely the one it bundles, so it depends directly on the version of the M2Eclipse plugin being used)

[Magnus]

Hello,

I found it!

The error is caused by the following dependency:

    <dependency>

      <groupId>msm.lib.acs</groupId>

      <artifactId>msm-lib-acs</artifactId>

      <version>1.0-SNAPSHOT</version>

      <!--

      <scope>provided</scope>

      -->

    </dependency>

The error immediately disappears when I set the scope to provided again.

Now I can enable dependency resolution in eclipse again.

So far so good. But I also remember why I removed the provided scope.

Juan recommended this in another thread as a solution to another problem:

My app uses my lib (msm.lib.acs above), and my lib uses common libs from the maven repository, e. g. postgresql-42.0.0.jar.

The problem was that those libs were not copied into the application's WEB-INF/lib folder. So I ended up in missing jars.

And unfortunately this problem now reappeared. When I build the app with "mvn package", I end ab with a WEB-INF/lib folder not containing the external libs!

So I made one step backward, dependency resolution is enabled again, but the external jars are missing in the app folder.

Maybe another scope is better?

Magnus

[Thomas Broyer]

This is expected: scope=provided means "this will be provided by 'the environment'" so it's not packaged inside the WAR (and transitive dependencies as well, of course).

And because the error you're having specifically happens when trying to copy the JAR into the WEB-INF/lib, if you say that this should no longer happen (by using scope=provided), then the error goes away.

 

Maybe another scope is better?

No.

The problem is that Eclipse wants to package your app.

As hinted in my other message, maybe this has been worked around in more recent versions of the maven-war-plugin (though I still believe the problem is with Eclipse and trying to package the app on project import) 

[Magnus]

The external libs (like postgresql-40.0.0.jar) must be copied into the WEB-INF/lib directory. When scope=provided, it isn't copied there. That was the problem in the other thread.

How can I solve this?

Note that this other problem from the other thread, where the "solution" was to remove scope=provided, is completely outside eclipse:

When I "mvn package" my app, the postgresql lib is not copied into the lib folder.

Magnus

[Thomas Broyer]

On Saturday, April 22, 2017 at 1:43:33 PM UTC+2, Magnus wrote:

The external libs (like postgresql-40.0.0.jar) must be copied into the WEB-INF/lib directory. When scope=provided, it isn't copied there. That was the problem in the other thread.

How can I solve this?

Don't use scope=provided.

What scope=provided says is exactly what you see is happening: please don't put those things into the WAR as they will be provided at runtime (put into Tomcat's "common" libraries, Jetty's lib/ext or extraClasspath, or anything equivalent in other servlet containers).

[Magnus]

There may be some misunderstandings:

The question scope=provided or not affects the dependency for my own library "my-lib" in the pom.xml of my application "my-app".

• If I remove it, the "Failed to copy file for artifact" returns (= problem 1).
  
• If I keep it, the external libraries referenced by "my-lib" (like postgresql-40.0.0.jar) don't get copied into the WEB-INF/lib folder of "my-app" (problem 2).

So by changing scope=provided I can only choose between problem 1 and problem 2.

Now you said that problem 2 isn't a problem, because the external libraries are provided at runtime, e. g. by Tomcat.

Let's focus this point.

I am running my own Tomcat and when I deploy a WAR file, I don't want to care about the external libraries it needs.

Before Maven, there was no need for this, because the external libs were included in WEB-INF/lib.

Now - with Maven - I shall care about the libs a WAR file needs a second time?

I already have specified all the dependencies in the pom.xml of my-lib.

Why not include all the needed jar fiiles in WEB-INF/lib and have one WAR file that can be deployed as its own?

Magnus

[Thomas Broyer]

On Saturday, April 22, 2017 at 5:06:00 PM UTC+2, Magnus wrote:

There may be some misunderstandings:

The question scope=provided or not affects the dependency for my own library "my-lib" in the pom.xml of my application "my-app".

• If I remove it, the "Failed to copy file for artifact" returns (= problem 1).
  
• If I keep it, the external libraries referenced by "my-lib" (like postgresql-40.0.0.jar) don't get copied into the WEB-INF/lib folder of "my-app" (problem 2).

So by changing scope=provided I can only choose between problem 1 and problem 2.

Yep, between one correct build that doesn't import in Eclipse (because of Eclipse), or an "incorrect" build (from your requirements).

 

Now you said that problem 2 isn't a problem, because the external libraries are provided at runtime, e. g. by Tomcat.

No.

I'm saying you should not use scope=provided if that's not what you want (and it's not what you want, so don't use it), and find a solution (or workaround at least) for the Eclipse issue, which is BTW unrelated to GWT I believe.

You should IMO focus on the Maven part and get it right; then make it work in/with your IDE (and fully understand –and document– the changes you'll possibly need to make to make it work).

[Magnus]

The question scope=provided or not affects the dependency for my own library "my-lib" in the pom.xml of my application "my-app".

• If I remove it, the "Failed to copy file for artifact" returns (= problem 1).
  
• If I keep it, the external libraries referenced by "my-lib" (like postgresql-40.0.0.jar) don't get copied into the WEB-INF/lib folder of "my-app" (problem 2).

So by changing scope=provided I can only choose between problem 1 and problem 2.

Yep, between one correct build that doesn't import in Eclipse (because of Eclipse), or an "incorrect" build (from your requirements).

I am willing to learn, so my "requirements" may be wrong.

What do you recommend for my situation?

 

Now you said that problem 2 isn't a problem, because the external libraries are provided at runtime, e. g. by Tomcat.

No.

I'm saying you should not use scope=provided if that's not what you want (and it's not what you want, so don't use it), and find a solution (or workaround at least) for the Eclipse issue,

I believe it's not an eclipse issue: I create a war file with "mvn package" and this war file doesn't contain the necessaey libs.

Tell me, where is my error in reasoning?

 You should IMO focus on the Maven part and get it right; then make it work in/with your IDE

Well, we have passed some milestones in this thread (eclipse error, scope=provided yes or no).

But at the point we are now, it's nothing but a Maven issue:
Creating a package with maven (mvn package) creates a package (war) with missing jar files.

To make a long story short:

• Before Maven I created a war file with all necessary jar files in WEB-INF/lib
• With Maven this war file is actually missing those jar files.

Please don't pay too much attention on my "requirements". They may be wrong, since I don't know how it should be done the usual way...

Magnus

[Thomas Broyer]

Your requirements is to have the JARs into the WAR (just like most other people, so your requirements aren't wrong), so DO NOT use scope=provided.

Then this causes an issue when importing the project in Eclipse, when resolving dependencies from the workspace; this is an Eclipse issue, Maven is fine.

Workarounds:

• do not resolve dependencies from the workspace; but then you need to "mvn install" your library and this has a huge impact on the developer experience (the initial subject of this thread)
• if the error does not prevent you from working on the project, then ignore it.

But this is an Eclipse issue.

 

[Magnus]

Your requirements is to have the JARs into the WAR (just like most other people, so your requirements aren't wrong), so DO NOT use scope=provided.

 

Ok, but how can I have the JARs into the WAR then?
If this is what most other people want, then there must be a solution...

Magnus

[Jens]

Ok, but how can I have the JARs into the WAR then?

If this is what most other people want, then there must be a solution...

As Thomas said, once you DO NOT use provided = true your library and all its required dependencies will end up in your WAR file. You just have to solve or ignore the Eclipse error.

-- J.

[Magnus]

Hello Jens,

I'm beginning to realize that removing scope=provided isn't a solution to the eclipse problem.
Sorry that this took so long...

However, then let's come back to the eclipse error again:

org.apache.maven.plugin.MojoExecutionException: Failed to copy file for artifact [msm.lib.acs:msm-lib-acs:jar:1.0-SNAPSHOT:compile]

...

Caused by: java.io.FileNotFoundException: /home/wagner/dvl/prj/msm/msm-lib-acs/target/classes (Is a directory)

 

I see two approaches then:

• solve the eclipse error without removing scope=provided
  Does anyone have an idea what may be causing the eclipse error? What file is not found? What is the process behind this file access? Can you solve it by placing a dummy file somewhere?
  
  
• using another maven plugin
  As some of you may have noticed in another thread, I was evaluating both, Mojo's and Thomas' eclipse plugin. Then, I saw that I can live with the pom.xml created by webAppCreator, without really caring about which plugin is used then.
  But I thought it was the "GWT way to go", since the pom was created by webAppCreator, which is shipped with the GWT SDK.
  
  However, in this thread, Thomas said that the Mojo-Haus plugin doesn't work in reactor builds. But I was unsure what I am actually using. When looking into my pom.xml I see a plugin with groupId = net.ltgt.gwt.maven. This seems to refer to Thomas' plugin. But in contrast, the error message refers to "MojoExecutionException". Sorry, but I still cannot follow this. Which plugin am I using? And if it's the "wrong" one, how can I switch in my existing pom.xml?

There seem to exist people without those problems. I simply want to do it the same way.

Magnus

[Thomas Broyer]

On Sunday, April 23, 2017 at 2:17:04 AM UTC+2, Magnus wrote:

Hello Jens,

I'm beginning to realize that removing scope=provided isn't a solution to the eclipse problem.
Sorry that this took so long...

However, then let's come back to the eclipse error again:

org.apache.maven.plugin.MojoExecutionException: Failed to copy file for artifact [msm.lib.acs:msm-lib-acs:jar:1.0-SNAPSHOT:compile]

...

Caused by: java.io.FileNotFoundException: /home/wagner/dvl/prj/msm/msm-lib-acs/target/classes (Is a directory)

 

I see two approaches then:

• solve the eclipse error without removing scope=provided
  Does anyone have an idea what may be causing the eclipse error? What file is not found? What is the process behind this file access? Can you solve it by placing a dummy file somewhere?
  

Again: Eclipse tries (for some unknown reason) to package your webapp, so it needs to copy the library into the WEB-INF/lib. But because you have Eclipse resolve dependencies from the workspace, it will resolve to the lib's target/classes (because it won't package the lib –don't ask me why, M2Eclipse decision, Maven's weird/broken lifecycles–), and thus copying fails because the maven-war-plugin expects a JAR file and not a directory.

The root problem is that Eclipse wants to package the webapp.

As said several times already, you can workaround this by disabling "resolve dependencies from the workspace", but then you have to "mvn install" the library, and it severely hurts the developer experience (the original subject of this thread).

You may also want to use a more recent maven-war-plugin version, just in case…

The solution though is to go ask Eclipse/M2Eclipse experts why the hell Eclipse wants to package your webapp. And to do that, you need to make the smallest possible project that reproduces the problem.

• using another maven plugin
  As some of you may have noticed in another thread, I was evaluating both, Mojo's and Thomas' eclipse plugin. Then, I saw that I can live with the pom.xml created by webAppCreator, without really caring about which plugin is used then.
  But I thought it was the "GWT way to go", since the pom was created by webAppCreator, which is shipped with the GWT SDK.
  
  However, in this thread, Thomas said that the Mojo-Haus plugin doesn't work in reactor builds. But I was unsure what I am actually using. When looking into my pom.xml I see a plugin with groupId = net.ltgt.gwt.maven. This seems to refer to Thomas' plugin. But in contrast, the error message refers to "MojoExecutionException". Sorry, but I still cannot follow this. Which plugin am I using? And if it's the "wrong" one, how can I switch in my existing pom.xml?

Again, "mojo" is a Maven term; the MojoExecutionException comes from Maven. This is different from MojoHaus, which just happens to (unfortunately and confusingly) reuse the term.

Note: the fact you have an error about the MojoHaus plugin when running "gwt:devmode" in the root project is because you don't explicitly use the net.ltgt.gwt.maven plugin in this project, and Maven defaults to trying out plugins from org.codehaus.mojo.

 

There seem to exist people without those problems. I simply want to do it the same way.

Last I tried (a while ago), things worked OK in Eclipse: it didn't try to package the webapp so it wasn't causing this error in the maven-war-plugin.

Again: the problem is the Eclipse wants to package your webapp; you need to figure out why and how to turn it off. And I believe this has nothing to do with the fact that you use GWT in your project (except possibly that it'll enable some behaviors in Eclipse; isolating the smallest possible project that triggers the error would determine whether this is the case).

It could be due to some Eclipse plugin you have installed, possibly even the GWT Eclipse Plugin, or to some configuration in your Eclipse install that differs from the default one.

[Ignacio Baca Moreno-Torres]

If you want to do it the same way just use the modular webapp-archetype (https://github.com/tbroyer/gwt-maven-archetypes/blob/master/README.md) 😬👍 videos here (GWT Eclipse Plugin V3: https://www.youtube.com/playlist?list=PLBbgqtDgdc_TqzA-qXrjgTFMC_6DKAQyT). Please, watch all the videos! 😉

[Pavlo Iatsiuk]

Yes, I do everything from command line with maven

to run war file

• mvn jetty:run-war -Djetty.port=8095 -DskipTests=true
  

to run code server

• mvn gwt:run-codeserver

gwt maven plugin settings

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>gwt-maven-plugin</artifactId>
    <version>${VERSION.GWT}</version>
    <configuration>
        <runTarget>MyPage.html</runTarget>
        <module>com.mycompany.EntryPoint</module>
        <sourceLevel>1.7</sourceLevel>
        <port>8095</port>
        <codeServerWorkDir>${project.build.directory}</codeServerWorkDir>
        <logLevel>INFO</logLevel>
        <extraJvmArgs>-Xmx1024M -Xms256M</extraJvmArgs>
        <gwtSdkFirstInClasspath>true</gwtSdkFirstInClasspath>
    </configuration>
    <executions>
        <execution>
            <goals>
                <goal>compile</goal>
            </goals>
        </execution>
    </executions>
    <dependencies>
        <dependency>
            <groupId>com.google.gwt</groupId>
            <artifactId>gwt-dev</artifactId>
            <version>${VERSION.GWT}</version>
        </dependency>
        <dependency>
            <groupId>com.google.gwt</groupId>
            <artifactId>gwt-codeserver</artifactId>
            <version>${VERSION.GWT}</version>
        </dependency>
    </dependencies>
</plugin>

And because I use gwt 2.6 - gwt settings:
<add-linker name="xsiframe"/>
<set-configuration-property name="devModeRedirectEnabled" value="true"/>
<set-configuration-property name='xsiframe.failIfScriptTag' value='false'/>

[Pavlo Iatsiuk]

Magnus, if you still have a problem to run it  - I can create a small "hello world" to show you how to do that with maven

[Magnus]

Friends,

it seems as if I could solve the problem by adding this to the pom.xml:

      <plugin>

       <groupId>org.apache.maven.plugins</groupId>

       <artifactId>maven-war-plugin</artifactId>

       <version>2.6</version>

      </plugin>

As you can see in the error message, version 2.2. is used by default. By changing it to 2.6 the error disappeared!

I am happy to have a solution, but I wonder what was going on. Why istn't the newest plugin used by default? I have seen that there already is a version 3.0.0 of the plugin.
Should I hardcode the version in the pom.xml?

However, now that the error disappeared, I'll come back to the original question and see how it speeds up the development process.

Thanks for your patience! .-)

Magnus

[Ignacio Baca Moreno-Torres]

But please, use the tbroyer plugin, it's much better, makes no sense start a new project using the old one. I also think that using maven makes a pretty reasonable development lifecycle, I just use the IDE to run the maven goals, works perfectly, much easier to configure and get it work. The tbroyer archetype can be used, gwt don't make sense to be executed in debug mode, and the sever side, tomcat, can be executed as develop maven goal and works in eclipse and IntelliJ.

El lun., 24 abr. 2017 13:46, Pavlo Iatsiuk <pavel....@gmail.com> escribió:

Magnus, if you still have a problem to run it  - I can create a small "hello world" to show you how to do that with maven

--

[Jens]

I am happy to have a solution, but I wonder what was going on. Why istn't the newest plugin used by default? I have seen that there already is a version 3.0.0 of the plugin.
Should I hardcode the version in the pom.xml?

To get a reproducible build the version of all your dependencies / plugins must be hardcoded into the pom.xml. I have no idea why Maven uses these older versions as default, maybe because they fear breaking people who have not specified a plugin version in their pom.xml.

-- J.

[Thomas Broyer]

On Monday, April 24, 2017 at 5:30:14 PM UTC+2, Magnus wrote:

Friends,

it seems as if I could solve the problem by adding this to the pom.xml:

      <plugin>

       <groupId>org.apache.maven.plugins</groupId>

       <artifactId>maven-war-plugin</artifactId>

       <version>2.6</version>

      </plugin>

As you can see in the error message, version 2.2. is used by default. By changing it to 2.6 the error disappeared!

I am happy to have a solution, but I wonder what was going on. Why istn't the newest plugin used by default? I have seen that there already is a version 3.0.0 of the plugin.

Plugin versions for default / built-in lifecycles depend on the version of Maven being used (which, in Eclipse, generally depends –by default at least– on the version of the M2Eclipse plugin).

IIRC, in recent versions of Maven, versions no longer change (so that you don't get too much different results just by updating Maven).

It happens that version 2.2 is used even in the latest 3.5.0 version: https://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html#Plugin_bindings_for_war_packaging

(same for the oldish 3.1.1: https://maven.apache.org/ref/3.1.1/maven-core/default-bindings.html#Plugin_bindings_for_war_packaging, but 3.0.5 used an earlier version https://maven.apache.org/ref/3.0.5/maven-core/default-bindings.html#Bindings_for_war_packaging)

 

Should I hardcode the version in the pom.xml?

Yes, it's a good practice (you can either put it in build/plugins or in build/pluginManagement/plugins; most will prefer pluginManagement for "pinning" versions but both will work)

However, now that the error disappeared, I'll come back to the original question and see how it speeds up the development process.

Now that you can have "resolve dependencies from the workspace" enabled in Eclipse, the GWT Eclipse Plugin should automatically configure the launch configuration to use the Eclipse project for the library and its source folders; that means you don't need to "mvn install" and restart the dev mode. So, problem solved?

(and with a reactor build, using and configuring net.ltgt.gwt.maven:gwt-maven-plugin:devmode in the root project, you get a similar behavior, from the command line)

Note that this is for client-side dependencies; things might/will be different for server-side dependencies. The GWT Eclipse Plugin has good integration with Eclipse WTP to make things even better (I've been told). See the videos you've been pointed to several times already.

Outside Eclipse, you'd have to run "mvn package -Dgwt.compiler.skip" to re-package the webapp so that devmode can pick up the new JAR for the lib (with "refresh server"). Though I'd recommend use gwt:codeserver instead of gwt:devmode and use something else for the server-side (such as tomcat7:run, or possibly jetty:start with some ugly hacks).

[Magnus]

However, now that the error disappeared, I'll come back to the original question and see how it speeds up the development process.

Now that you can have "resolve dependencies from the workspace" enabled in Eclipse, the GWT Eclipse Plugin should automatically configure the launch configuration to use the Eclipse project for the library and its source folders; that means you don't need to "mvn install" and restart the dev mode. So, problem solved?

Looks good! It's also fine that I don't need to explicitely include the library source code in the jar anymore.

However, when debugging and seeing a problem in server-side library code, I still have to stop the debugger, fix the problem and restart the debugging session. Can this also be improved? (There is a button "reload web server" in eclipse).

 

(and with a reactor build, using and configuring net.ltgt.gwt.maven:gwt-maven-plugin:devmode in the root project, you get a similar behavior, from the command line)

This reactor stuff sounds interesting to me. I think I'll move my projects to the modular-webapp archetype, allthough I'm not happy with the fact that the three subprojects must be unique at the top-level. And they also have a different package structure. The projects created with webAppCreator have "client", "server" and "shared" in their package names, while modular-webapp doesn't. Since eclipse refactoring doesn't work on whole directory trees, this will be a lot of manual work...

Thanks

Magnus

[Vassilis Virvilis]

Not so sure. I can refactor across projects in eclipse...

--

You received this message because you are subscribed to the Google Groups "GWT Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsub...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.

Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

--

Vassilis Virvilis

[Thomas Broyer]

You need to "rebuild" the webapp when you make changes to it (but not recompile the GWT app), so "mvn package -Dgwt.compiler.skip"; then "reload web server".