How to deal with transitive maven dependencies?

[Magnus]

Hello,

my app uses a separate jar library, which in turn uses another jar file, e. g. a postgresql driver:

Maven project "mylib", pom.xml:

   <dependency>

    <groupId>org.postgresql</groupId>

    <artifactId>postgresql</artifactId>

    <version>42.0.0</version>

   </dependency>

Maven project "myapp", pom.xml:

    <dependency>

      <groupId>mylib</groupId>

      <artifactId>mylib</artifactId>

      <version>1.0-SNAPSHOT</version>

      <scope>provided</scope>

    </dependency>

When I build mylib with mvn package install, the PostgreSQL jar file is not included or downloaded.

Also when I build myapp with mvn package, the PostgreSQL jar is not fetched.

So I end up with a missing jar file.

I think (and also strongly hope) that it's one of the strengths of Maven that I do not have to repeat the dependency in the myapp project?

Maybe this has something to do with the fact, that no class of the PostgreSQL jar file is referenced directly, and therefore not seen by the compiler. When the PostgreSQL driver is needed, it's loaded by a String:

Class.forName ("org.postgresql.Driver");

How can you include all dependent libraries in the final app package?

Thanks
Magnus

[Juan Pablo Gardella]

Did you put it in dependency or dependencyManagement section ? Share the complete pom files if you can-

--
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.

[Magnus]

I have everything in the dependency section.

Here are the complete pom files.

Note that "mylib" is "msm-lib-acs" and "myapp" is "msm-app-mcs" (I am still struggeling with the Maven naming conventions.):

mylib aka msm-lib-acs, 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.lib.acs</groupId>

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

  <packaging>jar</packaging>

  <version>1.0-SNAPSHOT</version>

  <name>msm-lib-acs</name>

  <url>http://maven.apache.org</url>

  <properties>

   <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

   <maven.compiler.source>1.8</maven.compiler.source>

   <maven.compiler.target>1.8</maven.compiler.target>

  </properties>

  <dependencies>

    <dependency>

      <groupId>junit</groupId>

      <artifactId>junit</artifactId>

      <version>3.8.1</version>

<!--

      <scope>test</scope>

-->

    </dependency>

    <dependency>

     <groupId>javax.mail</groupId>

     <artifactId>javax.mail-api</artifactId>

     <version>1.5.6</version>

    </dependency>

    <dependency>

     <groupId>javax.servlet</groupId>

     <artifactId>javax.servlet-api</artifactId>

     <version>3.1.0</version>

    </dependency>

    <dependency>

     <groupId>com.google.gwt</groupId>

     <artifactId>gwt-user</artifactId>

     <version>2.8.0</version>

     <scope>provided</scope>

    </dependency>

   <dependency>

    <groupId>mysql</groupId>

    <artifactId>mysql-connector-java</artifactId>

    <version>6.0.6</version>

   </dependency>

   

   <dependency>

    <groupId>org.postgresql</groupId>

    <artifactId>postgresql</artifactId>

    <version>42.0.0</version>

   </dependency>

  </dependencies>

<build>

  <resources>

    <resource>

      <directory>src/main/resources</directory>

    </resource>

    <resource>

      <directory>src/main/java</directory>

      <includes>

        <include>msm/lib/acs/awi/**/*.java</include>

        <include>msm/lib/acs/**/*.gwt.xml</include>

        <include>msm/lib/acs/awi/**/*.css</include>

        <include>msm/lib/acs/awi/**/*.png</include>

      </includes>

    </resource>

  </resources>

</build>

</project>

myapp aka msm-app-mcs, pom.xml:

<?xml version="1.0" encoding="UTF-8"?>

<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">

  <!-- POM file generated with GWT webAppCreator -->

  <modelVersion>4.0.0</modelVersion>

  <groupId>msm.app.mcs</groupId>

  <artifactId>msm-app-mcs</artifactId>

  <packaging>war</packaging>

  <version>1.0-SNAPSHOT</version>

  <name>msm.app.mcs.Application</name>

  <properties>

    <!-- Setting maven.compiler.source to something different to 1.8

         needs that you configure the sourceLevel in gwt-maven-plugin since

         GWT compiler 2.8 requires 1.8 (see gwt-maven-plugin block below) -->

    <maven.compiler.source>1.8</maven.compiler.source>

    <maven.compiler.target>1.8</maven.compiler.target>

    <!-- Don't let your Mac use a crazy non-standard encoding -->

    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>

  </properties>

  <dependencyManagement>

    <dependencies>

      <!-- ensure all GWT deps use the same version (unless overridden) -->

      <dependency>

        <groupId>com.google.gwt</groupId>

        <artifactId>gwt</artifactId>

        <version>2.8.0</version>

        <type>pom</type>

        <scope>import</scope>

      </dependency>

    </dependencies>

  </dependencyManagement>

  <dependencies>

    <dependency>

      <groupId>com.google.gwt</groupId>

      <artifactId>gwt-servlet</artifactId>

      <scope>runtime</scope>

    </dependency>

    <dependency>

      <groupId>com.google.gwt</groupId>

      <artifactId>gwt-user</artifactId>

      <scope>provided</scope>

    </dependency>

    <dependency>

      <groupId>com.google.gwt</groupId>

      <artifactId>gwt-dev</artifactId>

      <scope>provided</scope>

    </dependency>

    <dependency>

      <groupId>junit</groupId>

      <artifactId>junit</artifactId>

      <version>4.11</version>

      <scope>test</scope>

    </dependency>

    

    <dependency>

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

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

      <version>1.0-SNAPSHOT</version>

      <scope>provided</scope>

    </dependency>

    

  </dependencies>

  <build>

    <!-- Output classes directly into the webapp, so that IDEs and "mvn process-classes" update them in DevMode -->

    <outputDirectory>${project.build.directory}/${project.build.finalName}/WEB-INF/classes</outputDirectory>

    <plugins>

      <!-- GWT Maven Plugin-->

      <plugin>

        <groupId>net.ltgt.gwt.maven</groupId>

        <artifactId>gwt-maven-plugin</artifactId>

        <version>1.0-rc-6</version>

        <executions>

          <execution>

            <goals>

              <goal>import-sources</goal>

              <goal>compile</goal>

              <goal>import-test-sources</goal>

              <goal>test</goal>

            </goals>

          </execution>

        </executions>

        <configuration>

          <moduleName>msm.app.mcs.Application</moduleName>

          <moduleShortName>Application</moduleShortName>

          <failOnError>true</failOnError>

          <!-- GWT compiler 2.8 requires 1.8, hence define sourceLevel here if you use

               a different source language for java compilation -->

          <sourceLevel>1.8</sourceLevel>

          <!-- Compiler configuration -->

          <compilerArgs>

            <!-- Ask GWT to create the Story of Your Compile (SOYC) (gwt:compile) -->

            <arg>-compileReport</arg>

            <arg>-XcompilerMetrics</arg>

          </compilerArgs>

          <!-- DevMode configuration -->

          <warDir>${project.build.directory}/${project.build.finalName}</warDir>

          <classpathScope>compile+runtime</classpathScope>

          <!-- URL(s) that should be opened by DevMode (gwt:devmode). -->

          <startupUrls>

            <startupUrl>Application.html</startupUrl>

          </startupUrls>

        </configuration>

      </plugin>

      <!-- Skip normal test execution, we use gwt:test instead -->

      <plugin>

        <artifactId>maven-surefire-plugin</artifactId>

        <version>2.17</version>

        <configuration>

          <skip>true</skip>

        </configuration>

      </plugin>

    </plugins>

  </build>

</project>

[Juan Pablo Gardella]

Are you sure postgres library group/artifactid/version is ok? Chek at https://mvnrepository.com/artifact/postgresql/postgresql 

[Magnus]

Yes! It's taken from the maven repository!

What about the dependencyManagement thing?

Magnus

[Juan Pablo Gardella]

Remove provided at 

 <dependency>

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

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

…

      <version>1.0-SNAPSHOT</version>

      <scope>provided</scope>

    </dependency>

--

[Magnus]

Remove provided at 

 <dependency>

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

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

…

      <version>1.0-SNAPSHOT</version>

      <scope>provided</scope>

    </dependency>

If I only remove <scope>provided</scope> (without replacing it with another scope), then the jar file is correctly copied into the WEB-INF/lib folder.

But then, I have an error marker in eclipse (at the line with <packaging>war</packaging>):

Description Resource Path Location Type

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/warker/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

pom.xml /msm-app-mcs line 9 Maven Build Problem

The directory /home/warker/dvl/prj/msm/msm-lib-acs/target/classes exists.

What's still wrong?

Thanks
Magnus

 

[Magnus]

Note that as soon as I set the scope back to provided the error is gone immediately.

Maybe another scope is needed here?

[Thomas Broyer]

Actually, nothing. Nothing on the Maven side though.

The problem is with M2Eclipse, but I don't know it enough to know how you're supposed to work with it and give you any guidance here.

The problem is that "mvn war:war" is somehow invoked (do you invoke it yourself manually, from within Eclipse? possibly as "mvn package") and it resolves its dependencies from the workspace (by default at least), similar to a reactor build.

But when resolving the library, it won't build/package it! and Maven's default behavior when trying to resolve unpackaged dependencies from a reactor build, is to take target/classes if the dependency has <packaging>jar</packaging>

This can happen in regular reactor builds when you e.g. run "mvn test": it'll run "mvn test" on the first submodule, then "mvn test" on the second submodule, and if the second submodule depends on the first one, then its target/classes is used (because "test" comes before "package" in the lifecycle). This is a design flaw in Maven (if you ask me), and one of the reasons I generally recommend using other builds tools (e.g. Gradle) instead.

If you disable resolution of dependencies from the workspace in Eclipse, then the "mvn war:war" will resolve the library from the local repository instead (which means you'd have to "mvn install" the library to have the app see the changes).

My (personal) recommendation is to work with reactor (multi-module) builds, to only ever execute Maven commands on the root module, and to only ever use the "package" and "verify" lifecycle phases (and possibly "install" and/or "deploy" if you really need them). This is one reason I built the net.ltgt.gwt.maven:gwt-maven-plugin, because the old org.codehaus.mojo:gwt-maven-plugin could work that way. Similarly, the tomcat7-maven-plugin works with reactor builds, but not the jetty-maven-plugin.

But some people are OK with doing "mvn install" every few minutes…

[Magnus]

Hello Thomas,

thank you very much, but I only understand parts of your posts, because maven is still new to me...

Actually, nothing. Nothing on the Maven side though.

Yes, I can validate this by doing mvn gwt:devmode and the app works, nevertheless what eclipse thinks is wrong...

 

The problem is with M2Eclipse, but I don't know it enough to know how you're supposed to work with it and give you any guidance here.

Well, I was used to do everything in eclipse: create gwt project, compile, run, debug, ... I just migrated one general library (pure java and gwt code) and two apps (which I recreated with webAppCreator -templates maven) to maven.

When I make changes to the library, I execute mvn clean compile package install. I feel that some of these goals should be triggered by others, but I call them all to make sure to end up in a defined state.

When I make changes to one of the apps, I execute mvn clean compile package gwt:devmode.

I know that all these goals must be redundant and triggered by each other somehow, but during the migration of my projects I have seen many problems that disappeared when repeating the different maven goals...

The problem is that "mvn war:war" is somehow invoked (do you invoke it yourself manually, from within Eclipse? possibly as "mvn package") and it resolves its dependencies from the workspace (by default at least), similar to a reactor build.

To reproduce the problem I don't need to call anything: I simply open the pom.xml in eclipse, remove the "provided" scope, and save the pom.xml file. Then, immediately, the error marker appears.

BTW: I don't know "reactor builds", so I cannot follow your additional words:

 

But when resolving the library, it won't build/package it! and Maven's default behavior when trying to resolve unpackaged dependencies from a reactor build, is to take target/classes if the dependency has <packaging>jar</packaging>

This can happen in regular reactor builds when you e.g. run "mvn test": it'll run "mvn test" on the first submodule, then "mvn test" on the second submodule, and if the second submodule depends on the first one, then its target/classes is used (because "test" comes before "package" in the lifecycle). This is a design flaw in Maven (if you ask me), and one of the reasons I generally recommend using other builds tools (e.g. Gradle) instead.

If you disable resolution of dependencies from the workspace in Eclipse, then the "mvn war:war" will resolve the library from the local repository instead (which means you'd have to "mvn install" the library to have the app see the changes).

The only thing I understand in this paragraph is that I have to "mvn install" the library, what I am actually doing, so that the apps can see it.

Since my app works when doing everything on the command line, the only thing I want is that the error markers disappear (assuming that they are false positives)...

 

My (personal) recommendation is to work with reactor (multi-module) builds, to only ever execute Maven commands on the root module, and to only ever use the "package" and "verify" lifecycle phases (and possibly "install" and/or "deploy" if you really need them).

I would like to follow this recommendation, but what exactly do I have to do?

This is one reason I built the net.ltgt.gwt.maven:gwt-maven-plugin, because the old org.codehaus.mojo:gwt-maven-plugin could work that way.

This is one big questionmark for me! I am evaluating the different GWT maven plugins for a while, and I learned that yours is the one that is recommended. Then, I found that webAppCreator -templates maven creates a project template that I can work with. And I noticed net.ltgt.gwt.maven in the pom.xml. Therefore, I thought that I am using your plugin. But the error message discussed here is a "MojoExecutionException". The word "Mojo" seems to refer to the other plugin. That's confusing to me. Can you resolve this?

Magnus

[Thomas Broyer]

On Thursday, March 30, 2017 at 6:56:56 PM UTC+2, Magnus wrote:

Hello Thomas,

thank you very much, but I only understand parts of your posts, because maven is still new to me...

Actually, nothing. Nothing on the Maven side though.

Yes, I can validate this by doing mvn gwt:devmode and the app works, nevertheless what eclipse thinks is wrong...

 

The problem is with M2Eclipse, but I don't know it enough to know how you're supposed to work with it and give you any guidance here.

Well, I was used to do everything in eclipse: create gwt project, compile, run, debug, ... I just migrated one general library (pure java and gwt code) and two apps (which I recreated with webAppCreator -templates maven) to maven.

When I make changes to the library, I execute mvn clean compile package install. I feel that some of these goals should be triggered by others, but I call them all to make sure to end up in a defined state.

When I make changes to one of the apps, I execute mvn clean compile package gwt:devmode.

I know that all these goals must be redundant and triggered by each other somehow, but during the migration of my projects I have seen many problems that disappeared when repeating the different maven goals...

See my previous message (in another thread) where I touched those goals.

Hint: remember that Maven lifecycles are linear (they're not a graph), so "install" implies everything before it (includes "compile" and "package"; and "package" implies "compile").

For non-lifecycle goals (such as gwt:devmode), the doc tells you what lifecycle phase it triggers (and the doc is generated from annotations in the code that Maven actually use to determine what it has to do, so it's really documentation about the actual behavior, without a risk of disconnect or being outdated). In the case of gwt:devmode, it triggers "process-classes", which comes just after "compile" in the lifecycle (and as a rule of thumb, you should always use "process-classes" rather than "compile"): https://tbroyer.github.io/gwt-maven-plugin/devmode-mojo.html

 

The problem is that "mvn war:war" is somehow invoked (do you invoke it yourself manually, from within Eclipse? possibly as "mvn package") and it resolves its dependencies from the workspace (by default at least), similar to a reactor build.

To reproduce the problem I don't need to call anything: I simply open the pom.xml in eclipse, remove the "provided" scope, and save the pom.xml file. Then, immediately, the error marker appears.

BTW: I don't know "reactor builds", so I cannot follow your additional words:

See https://maven.apache.org/guides/mini/guide-multiple-modules.html

tl;fr: a "reactor build" is a build in a multi-module project (where one POM has <packaging>pom</packaging> and lists submodules in a <modules> element). The build has to be done on that one POM, not in a subfolder corresponding to a submodule (in which case it's just a normal build).

 

 

But when resolving the library, it won't build/package it! and Maven's default behavior when trying to resolve unpackaged dependencies from a reactor build, is to take target/classes if the dependency has <packaging>jar</packaging>

This can happen in regular reactor builds when you e.g. run "mvn test": it'll run "mvn test" on the first submodule, then "mvn test" on the second submodule, and if the second submodule depends on the first one, then its target/classes is used (because "test" comes before "package" in the lifecycle). This is a design flaw in Maven (if you ask me), and one of the reasons I generally recommend using other builds tools (e.g. Gradle) instead.

If you disable resolution of dependencies from the workspace in Eclipse, then the "mvn war:war" will resolve the library from the local repository instead (which means you'd have to "mvn install" the library to have the app see the changes).

The only thing I understand in this paragraph is that I have to "mvn install" the library, what I am actually doing, so that the apps can see it.

Since my app works when doing everything on the command line, the only thing I want is that the error markers disappear (assuming that they are false positives)...

Then all you should have to do is telling Eclipse to stop resolving dependencies from the workspace (and only from the local repository).

IIRC, right-click on the project,→ Maven → uncheck the menu item talking about resolving from the workspace.

See https://books.sonatype.com/m2eclipse-book/reference/eclipse.html#eclipse-sect-resolving-dependencies (this book is a bit old and no longer maintained)

It seems strange to me though that Eclipse would try to package the project, did you change the preferences of goals Eclipse should run on project import or when updating project configuration?

https://books.sonatype.com/m2eclipse-book/reference/preferences.html#preferences-sect-maven-preferences

 

 

My (personal) recommendation is to work with reactor (multi-module) builds, to only ever execute Maven commands on the root module, and to only ever use the "package" and "verify" lifecycle phases (and possibly "install" and/or "deploy" if you really need them).

I would like to follow this recommendation, but what exactly do I have to do?

Assuming you have a folder "project" containing two subfolders "lib" and "app" containing your library and application projects respectively, then create a pom.xml in "project" with <packaging>pom</packaging> and this snippet:

<modules>

  <module>lib</module>

  <module>app</module>

</modules>

Then run all your Maven commands in the "project" folder (never in the "lib" or "app" subfolders).

For gwt:devmode, you'll want to move the configuration up into this POM (and adapt the various paths and configuration). See my gwt-maven-archetypes for examples of this.

 

This is one reason I built the net.ltgt.gwt.maven:gwt-maven-plugin, because the old org.codehaus.mojo:gwt-maven-plugin could work that way.

This is one big questionmark for me! I am evaluating the different GWT maven plugins for a while, and I learned that yours is the one that is recommended. Then, I found that webAppCreator -templates maven creates a project template that I can work with. And I noticed net.ltgt.gwt.maven in the pom.xml. Therefore, I thought that I am using your plugin. But the error message discussed here is a "MojoExecutionException". The word "Mojo" seems to refer to the other plugin. That's confusing to me. Can you resolve this?

"Mojo" is a Maven term, it stands for "Maven plain Old Java Object": https://maven.apache.org/plugin-developers/

It's a bit unfortunate that the "community" of plugins was named "Mojo" (formerly CodeHaus Mojo, now MojoHaus) but there's nothing I can do.

[Magnus]

Hello Thomas,

sorry for the late answer...

Since my app works when doing everything on the command line, the only thing I want is that the error markers disappear (assuming that they are false positives)...

Then all you should have to do is telling Eclipse to stop resolving dependencies from the workspace (and only from the local repository).

IIRC, right-click on the project,→ Maven → uncheck the menu item talking about resolving from the workspace.

That was it! The error markers are gone! But I don't understand exactly what's going on here. Why do I see the MojoExecutionException when resolving dependencies is enabled? 

 

It seems strange to me though that Eclipse would try to package the project, did you change the preferences of goals Eclipse should run on project import or when updating project configuration?

No, I simply created the project with webAppCreator and selected "Import maven project"...

Assuming you have a folder "project" containing two subfolders "lib" and "app" containing your library and application projects respectively, then create a pom.xml in "project" with <packaging>pom</packaging> and this snippet:

<modules>

  <module>lib</module>

  <module>app</module>

</modules>

Then run all your Maven commands in the "project" folder (never in the "lib" or "app" subfolders).

Ok, sounds good.

I tried this with a pom containing only what you said, bur maven is missing groupId, artifactId and that. What would you call the groupId abd artifactId here?

 

Magnus