Re: How to deal with transitive maven dependencies?

On Thursday, March 30, 2017 at 4:57:04 PM UTC+2, Magnus wrote:

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?

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…

--
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+unsubscribe@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.