Re: mvn dependency:analyze fails with IllegalArgumentException
Hi Henrik, So I created a ticket for that: https://issues.apache.org/jira/browse/MDEP-603 So thanks for reporting this here...and of course for you feedback. Kind regards Karl Heinz Marbaise On 24/03/18 11:14, Henrik Eriksson wrote: Hi Karl, That worked! Regards Henrik 2018-03-23 19:35 GMT+01:00 Karl Heinz Marbaise : Hi Henrik, can you try to add the following to your pom configuration (just a try to see if I'm on the right path): org.apache.maven.plugins maven-dependency-plugin org.ow2.asm asm 6.1 and just give a try to rerun it... Kind regards Karl Heinz Marbaise On 21/03/18 23:02, Henrik Eriksson wrote: Hello, Running mvn dependency:analyze fails with the follwing exception: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze (default-cli) on project utils: Execution default-cli of goal org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze failed.: IllegalArgumentException -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze (default-cli) on project utils: Execution default-cli of goal org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze failed. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj oExecutor.java:213) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj oExecutor.java:154) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj oExecutor.java:146) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.b uildProject(LifecycleModuleBuilder.java:117) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.b uildProject(LifecycleModuleBuilder.java:81) at org.apache.maven.lifecycle.internal.builder.singlethreaded.S ingleThreadedBuilder.build(SingleThreadedBuilder.java:51) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345) at org.apache.maven.cli.MavenCli.main(MavenCli.java:191) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invo ke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl. invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnha nced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch( Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithEx itCode(Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main( Launcher.java:356) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-cli of goal org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMoj o(DefaultBuildPluginManager.java:145) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj oExecutor.java:208) ... 20 more Caused by: java.lang.IllegalArgumentException at org.objectweb.asm.ClassReader.(Unknown Source) at org.objectweb.asm.ClassReader.(Unknown Source) at org.objectweb.asm.ClassReader.(Unknown Source) at org.apache.maven.shared.dependency.analyzer.asm.DependencyCl assFileVisitor.visitClass(DependencyClassFileVisitor.java:65) at org.apache.maven.shared.dependency.analyzer.ClassFileVisitor Utils.visitClass(ClassFileVisitorUtils.java:163) at org.apache.maven.shared.dependency.analyzer.ClassFileVisitor Utils.acceptDirectory(ClassFileVisitorUtils.java:143) at org.apache.maven.shared.dependency.analyzer.ClassFileVisitor Utils.accept(ClassFileVisitorUtils.java:71) at org.apache.maven.shared.dependency.analyzer.asm.ASMDependenc yAnalyzer.analyze(ASMDependencyAnalyzer.java:50) at org.apache.maven.shared.dependency.analyzer.DefaultProjectDe pendencyAnalyzer.buildDependencyClasses(DefaultProjectDependencyAnalyzer. java:211) at org.apache.maven.shared.dependency.analyzer.DefaultProjectDe pendencyAnalyzer.buildDependencyClasses(DefaultProjectDependencyAnalyzer. java:198) at org.apache.maven.shared.dependency.analyzer.DefaultProjectDe pendencyAnalyzer.analyze(DefaultProjectDependencyAnalyzer.java:74) at org.apache.maven.plugins.dependency.analyze.AbstractAnalyzeM ojo.checkDependencies(AbstractAnalyzeMojo.java:298) at org.apache.maven.plugins.dependency.analyze.AbstractAnalyzeM ojo.execute(AbstractAnalyzeMojo.java:250) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMoj o(DefaultBuildPluginManager.java:134) ... 21 more [ERROR] [ERROR] [ERROR] For more information a
Re: mvn dependency:analyze fails with IllegalArgumentException
Hi Karl, That worked! Regards Henrik 2018-03-23 19:35 GMT+01:00 Karl Heinz Marbaise : > Hi Henrik, > > can you try to add the following to your pom configuration (just a try to > see if I'm on the right path): > > > > org.apache.maven.plugins > maven-dependency-plugin > > > org.ow2.asm > asm > 6.1 > > > > > and just give a try to rerun it... > > Kind regards > Karl Heinz Marbaise > > > On 21/03/18 23:02, Henrik Eriksson wrote: > >> Hello, >> >> Running mvn dependency:analyze fails with the follwing exception: >> >> [ERROR] Failed to execute goal >> org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze >> (default-cli) on project utils: Execution default-cli of goal >> org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze failed.: >> IllegalArgumentException -> [Help 1] >> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute >> goal org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze >> (default-cli) on project utils: Execution default-cli of goal >> org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze failed. >> at >> org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj >> oExecutor.java:213) >> at >> org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj >> oExecutor.java:154) >> at >> org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj >> oExecutor.java:146) >> at >> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.b >> uildProject(LifecycleModuleBuilder.java:117) >> at >> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.b >> uildProject(LifecycleModuleBuilder.java:81) >> at >> org.apache.maven.lifecycle.internal.builder.singlethreaded.S >> ingleThreadedBuilder.build(SingleThreadedBuilder.java:51) >> at >> org.apache.maven.lifecycle.internal.LifecycleStarter.execute >> (LifecycleStarter.java:128) >> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309) >> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194) >> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107) >> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993) >> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345) >> at org.apache.maven.cli.MavenCli.main(MavenCli.java:191) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invo >> ke(NativeMethodAccessorImpl.java:62) >> at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl. >> invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:564) >> at >> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnha >> nced(Launcher.java:289) >> at >> org.codehaus.plexus.classworlds.launcher.Launcher.launch( >> Launcher.java:229) >> at >> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithEx >> itCode(Launcher.java:415) >> at org.codehaus.plexus.classworlds.launcher.Launcher.main( >> Launcher.java:356) >> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution >> default-cli of goal >> org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze failed. >> at >> org.apache.maven.plugin.DefaultBuildPluginManager.executeMoj >> o(DefaultBuildPluginManager.java:145) >> at >> org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj >> oExecutor.java:208) >> ... 20 more >> Caused by: java.lang.IllegalArgumentException >> at org.objectweb.asm.ClassReader.(Unknown Source) >> at org.objectweb.asm.ClassReader.(Unknown Source) >> at org.objectweb.asm.ClassReader.(Unknown Source) >> at >> org.apache.maven.shared.dependency.analyzer.asm.DependencyCl >> assFileVisitor.visitClass(DependencyClassFileVisitor.java:65) >> at >> org.apache.maven.shared.dependency.analyzer.ClassFileVisitor >> Utils.visitClass(ClassFileVisitorUtils.java:163) >> at >> org.apache.maven.shared.dependency.analyzer.ClassFileVisitor >> Utils.acceptDirectory(ClassFileVisitorUtils.java:143) >> at >> org.apache.maven.shared.dependency.analyzer.ClassFileVisitor >> Utils.accept(ClassFileVisitorUtils.java:71) >> at >> org.apache.maven.shared.dependency.analyzer.asm.ASMDependenc >> yAnalyzer.analyze(ASMDependencyAnalyzer.java:50) >> at >> org.apache.maven.shared.dependency.analyzer.DefaultProjectDe >
Re: mvn dependency:analyze fails with IllegalArgumentException
Hi Henrik, can you try to add the following to your pom configuration (just a try to see if I'm on the right path): org.apache.maven.plugins maven-dependency-plugin org.ow2.asm asm 6.1 and just give a try to rerun it... Kind regards Karl Heinz Marbaise On 21/03/18 23:02, Henrik Eriksson wrote: Hello, Running mvn dependency:analyze fails with the follwing exception: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze (default-cli) on project utils: Execution default-cli of goal org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze failed.: IllegalArgumentException -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze (default-cli) on project utils: Execution default-cli of goal org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze failed. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345) at org.apache.maven.cli.MavenCli.main(MavenCli.java:191) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-cli of goal org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) ... 20 more Caused by: java.lang.IllegalArgumentException at org.objectweb.asm.ClassReader.(Unknown Source) at org.objectweb.asm.ClassReader.(Unknown Source) at org.objectweb.asm.ClassReader.(Unknown Source) at org.apache.maven.shared.dependency.analyzer.asm.DependencyClassFileVisitor.visitClass(DependencyClassFileVisitor.java:65) at org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass(ClassFileVisitorUtils.java:163) at org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.acceptDirectory(ClassFileVisitorUtils.java:143) at org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.accept(ClassFileVisitorUtils.java:71) at org.apache.maven.shared.dependency.analyzer.asm.ASMDependencyAnalyzer.analyze(ASMDependencyAnalyzer.java:50) at org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildDependencyClasses(DefaultProjectDependencyAnalyzer.java:211) at org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildDependencyClasses(DefaultProjectDependencyAnalyzer.java:198) at org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.analyze(DefaultProjectDependencyAnalyzer.java:74) at org.apache.maven.plugins.dependency.analyze.AbstractAnalyzeMojo.checkDependencies(AbstractAnalyzeMojo.java:298) at org.apache.maven.plugins.dependency.analyze.AbstractAnalyzeMojo.execute(AbstractAnalyzeMojo.java:250) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) ... 21 more [ERROR] [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/PluginExecutionException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command mvn --verison Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00) Maven hom
mvn dependency:analyze fails with IllegalArgumentException
Hello, Running mvn dependency:analyze fails with the follwing exception: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze (default-cli) on project utils: Execution default-cli of goal org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze failed.: IllegalArgumentException -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze (default-cli) on project utils: Execution default-cli of goal org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze failed. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345) at org.apache.maven.cli.MavenCli.main(MavenCli.java:191) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-cli of goal org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) ... 20 more Caused by: java.lang.IllegalArgumentException at org.objectweb.asm.ClassReader.(Unknown Source) at org.objectweb.asm.ClassReader.(Unknown Source) at org.objectweb.asm.ClassReader.(Unknown Source) at org.apache.maven.shared.dependency.analyzer.asm.DependencyClassFileVisitor.visitClass(DependencyClassFileVisitor.java:65) at org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass(ClassFileVisitorUtils.java:163) at org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.acceptDirectory(ClassFileVisitorUtils.java:143) at org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.accept(ClassFileVisitorUtils.java:71) at org.apache.maven.shared.dependency.analyzer.asm.ASMDependencyAnalyzer.analyze(ASMDependencyAnalyzer.java:50) at org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildDependencyClasses(DefaultProjectDependencyAnalyzer.java:211) at org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildDependencyClasses(DefaultProjectDependencyAnalyzer.java:198) at org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.analyze(DefaultProjectDependencyAnalyzer.java:74) at org.apache.maven.plugins.dependency.analyze.AbstractAnalyzeMojo.checkDependencies(AbstractAnalyzeMojo.java:298) at org.apache.maven.plugins.dependency.analyze.AbstractAnalyzeMojo.execute(AbstractAnalyzeMojo.java:250) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) ... 21 more [ERROR] [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/PluginExecutionException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command mvn --verison Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00) Maven home: /home/omit/bin/maven Java version: 9.0.4, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-9-oracle Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "4.13.0-37-generic", arch: "amd64", family: "unix" Does anyone know what that might be? /H
Re: How does mvn dependency:analyze work?
It only checks against direct dependencies for unused declared dependencies. "declared dependencies" are direct dependencies. /Anders (mobile) Den 18 jan. 2018 14:45 skrev "Debraj Manna" : Thanks Filipe . Any thoughts about my second query - Does Unused declared dependencies found check only for the direct dependencies declared in pom.xml or it checks transitive dependencies as well? On Thu, Jan 18, 2018 at 3:34 PM, Filipe Sousa wrote: > From > http://books.sonatype.com/mvnex-book/reference/optimizing-sect-dependency- > plugin.html <http://books.sonatype.com/mvnex-book/reference/ > optimizing-sect-dependency-plugin.html> > > "A good rule of thumb in Maven is to always declare explicit dependencies > for classes referenced in your code.” > > From time to time I run dependency:analyze -DignoreNonCompile=true > -DoutputXML=true > > > On 18 Jan 2018, at 07:31, Debraj Manna wrote: > > > > Cross-posting from stackoverflow > > <https://stackoverflow.com/questions/48315863/how-does- > mvn-dependencyanalyze-work> > > > > Can someone let me know how does mvn dependency:analyze work ? An output > of mvn > > dependency:analyze in one of my project shows > > > > [WARNING] Used undeclared dependencies found:[WARNING] > > org.apache.commons:commons-lang3:jar:3.4:compile[WARNING] > > com.fasterxml.jackson.core:jackson-annotations:jar:2.8.0: > compile...[WARNING] > > Unused declared dependencies found:[WARNING] > > org.springframework.boot:spring-boot-starter-test:jar: > 1.5.4.RELEASE:test[WARNING] > > org.springframework.restdocs:spring-restdocs-mockmvc:jar:1. > 1.3.RELEASE:test[WARNING] > > ch.qos.logback:logback-classic:jar:1.1.11:compile > > > > Can some one let me know the following - > > > > - What does Used undeclared dependencies found denote? Does it mean > that > > this is not declared in pom.xml dependencies but getting used in code > > and is included via some transitive dependencies? > > - Does Unused declared dependencies found check only for the > > dependencies declared > > in pom.xml or it checks transitive dependencies as well? > > > > Maven Version - 3.5.0 > >
Re: How does mvn dependency:analyze work?
Thanks Filipe . Any thoughts about my second query - Does Unused declared dependencies found check only for the direct dependencies declared in pom.xml or it checks transitive dependencies as well? On Thu, Jan 18, 2018 at 3:34 PM, Filipe Sousa wrote: > From > http://books.sonatype.com/mvnex-book/reference/optimizing-sect-dependency- > plugin.html <http://books.sonatype.com/mvnex-book/reference/ > optimizing-sect-dependency-plugin.html> > > "A good rule of thumb in Maven is to always declare explicit dependencies > for classes referenced in your code.” > > From time to time I run dependency:analyze -DignoreNonCompile=true > -DoutputXML=true > > > On 18 Jan 2018, at 07:31, Debraj Manna wrote: > > > > Cross-posting from stackoverflow > > <https://stackoverflow.com/questions/48315863/how-does- > mvn-dependencyanalyze-work> > > > > Can someone let me know how does mvn dependency:analyze work ? An output > of mvn > > dependency:analyze in one of my project shows > > > > [WARNING] Used undeclared dependencies found:[WARNING] > > org.apache.commons:commons-lang3:jar:3.4:compile[WARNING] > > com.fasterxml.jackson.core:jackson-annotations:jar:2.8.0: > compile...[WARNING] > > Unused declared dependencies found:[WARNING] > > org.springframework.boot:spring-boot-starter-test:jar: > 1.5.4.RELEASE:test[WARNING] > > org.springframework.restdocs:spring-restdocs-mockmvc:jar:1. > 1.3.RELEASE:test[WARNING] > > ch.qos.logback:logback-classic:jar:1.1.11:compile > > > > Can some one let me know the following - > > > > - What does Used undeclared dependencies found denote? Does it mean > that > > this is not declared in pom.xml dependencies but getting used in code > > and is included via some transitive dependencies? > > - Does Unused declared dependencies found check only for the > > dependencies declared > > in pom.xml or it checks transitive dependencies as well? > > > > Maven Version - 3.5.0 > >
Re: How does mvn dependency:analyze work?
From http://books.sonatype.com/mvnex-book/reference/optimizing-sect-dependency-plugin.html <http://books.sonatype.com/mvnex-book/reference/optimizing-sect-dependency-plugin.html> "A good rule of thumb in Maven is to always declare explicit dependencies for classes referenced in your code.” From time to time I run dependency:analyze -DignoreNonCompile=true -DoutputXML=true > On 18 Jan 2018, at 07:31, Debraj Manna wrote: > > Cross-posting from stackoverflow > <https://stackoverflow.com/questions/48315863/how-does-mvn-dependencyanalyze-work> > > Can someone let me know how does mvn dependency:analyze work ? An output of > mvn > dependency:analyze in one of my project shows > > [WARNING] Used undeclared dependencies found:[WARNING] > org.apache.commons:commons-lang3:jar:3.4:compile[WARNING] > com.fasterxml.jackson.core:jackson-annotations:jar:2.8.0:compile...[WARNING] > Unused declared dependencies found:[WARNING] > org.springframework.boot:spring-boot-starter-test:jar:1.5.4.RELEASE:test[WARNING] > > org.springframework.restdocs:spring-restdocs-mockmvc:jar:1.1.3.RELEASE:test[WARNING] > ch.qos.logback:logback-classic:jar:1.1.11:compile > > Can some one let me know the following - > > - What does Used undeclared dependencies found denote? Does it mean that > this is not declared in pom.xml dependencies but getting used in code > and is included via some transitive dependencies? > - Does Unused declared dependencies found check only for the > dependencies declared > in pom.xml or it checks transitive dependencies as well? > > Maven Version - 3.5.0
How does mvn dependency:analyze work?
Cross-posting from stackoverflow <https://stackoverflow.com/questions/48315863/how-does-mvn-dependencyanalyze-work> Can someone let me know how does mvn dependency:analyze work ? An output of mvn dependency:analyze in one of my project shows [WARNING] Used undeclared dependencies found:[WARNING] org.apache.commons:commons-lang3:jar:3.4:compile[WARNING] com.fasterxml.jackson.core:jackson-annotations:jar:2.8.0:compile...[WARNING] Unused declared dependencies found:[WARNING] org.springframework.boot:spring-boot-starter-test:jar:1.5.4.RELEASE:test[WARNING] org.springframework.restdocs:spring-restdocs-mockmvc:jar:1.1.3.RELEASE:test[WARNING] ch.qos.logback:logback-classic:jar:1.1.11:compile Can some one let me know the following - - What does Used undeclared dependencies found denote? Does it mean that this is not declared in pom.xml dependencies but getting used in code and is included via some transitive dependencies? - Does Unused declared dependencies found check only for the dependencies declared in pom.xml or it checks transitive dependencies as well? Maven Version - 3.5.0
Re: dependency:analyze controversial result
activemq-all, as its name suggests, bundles third-party dependencies in its JAR (rather than declaring them as dependencies), and it happens to include slf4j: http://grepcode.com/snapshot/repo1.maven.org/maven2/org.apache.activemq/activemq-all/5.11.1 So I suppose, the first run finds slf4j classes in activemq-all so it marks the slf4j dependency as "unused declared". Do not ever use "uberjars" as dependencies, and report it upstream if it comes as a transitive dependency of a third party (and in the meantime, exclude the transitive dependency and add the proper non-uberjar dependencies instead). On Wed, May 17, 2017 at 10:14 AM Kristof Meixner < kristof.meix...@fatlenny.net> wrote: > Hi! > > Maybe I was too unclear about the specific problem. > > I've got a project that has org.slf4j:slf4j-api:1.7.12 as dependency as it > uses the Logger in the Java code. The > dependency is declared in POM but comes also as a transitive dependency. > > When running 'dependency:analyze' it is marked as 'unused declared'. When > I remove the dependency from the POM, and run > 'dependency:analyze' again it is marked as 'used undeclared'. Furthermore, > in the first case suddenly another dependency > [1] is marked as 'used undeclared' although it is never used directly. > > Best regards > Kristof > > [1] org.apache.activemq:activemq-all:5.11.1 > > On 05/16/2017 08:13 PM, Alexander Kriegisch wrote: > > Maybe because > > > > a) your project uses dependencies which were never declared explicitly > > in any of your POMs and > > b) at least some of your modules have dependencies declared which are > > not actually used in your code? > > > > What do you think? > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: dependency:analyze controversial result
Hi! Maybe I was too unclear about the specific problem. I've got a project that has org.slf4j:slf4j-api:1.7.12 as dependency as it uses the Logger in the Java code. The dependency is declared in POM but comes also as a transitive dependency. When running 'dependency:analyze' it is marked as 'unused declared'. When I remove the dependency from the POM, and run 'dependency:analyze' again it is marked as 'used undeclared'. Furthermore, in the first case suddenly another dependency [1] is marked as 'used undeclared' although it is never used directly. Best regards Kristof [1] org.apache.activemq:activemq-all:5.11.1 On 05/16/2017 08:13 PM, Alexander Kriegisch wrote: > Maybe because > > a) your project uses dependencies which were never declared explicitly > in any of your POMs and > b) at least some of your modules have dependencies declared which are > not actually used in your code? > > What do you think? > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: dependency:analyze controversial result
Maybe because a) your project uses dependencies which were never declared explicitly in any of your POMs and b) at least some of your modules have dependencies declared which are not actually used in your code? What do you think? -- Alexander Kriegisch https://scrum-master.de Kristof Meixner schrieb am 16.05.2017 19:50: > Hi! > > When I run 'mvn dependency:analyse' on my project several dependencies get > mentioned in the 'Used undeclared > dependencies' as well as in the 'Unused declared dependencies' section. Any > idea why? > > Best regards > Kristof Meixner - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
dependency:analyze controversial result
Hi! When I run 'mvn dependency:analyse' on my project several dependencies get mentioned in the 'Used undeclared dependencies' as well as in the 'Unused declared dependencies' section. Any idea why? Best regards Kristof Meixner - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Why is dependency:analyze lying to me?
Hello, you see this a lot with runtime dependencies (which should probably be ignored during analyze anyway), so I mostly just ignore these in the output. It would be a cool thing, if you could suppress warnings for gavs directly in the analyze goal, so you see new stuff coming up more easily. Regards Mirko -- Sent from my mobile On Feb 13, 2014 11:01 PM, "Wayne Fay" wrote: > > This may fall into the “How the hell is Maven supposed to know?” > category, > > Yes, it most certainly does. > > > [WARNING] > > > org.springframework.security:spring-security-taglibs:jar:3.1.1.RELEASE:compile > ... > > Anyway, not sure if the plugin can be configured to detect these kind of > > things, but a guy can dream, can’t he?? > > You would need to write code that performs the following tasks: > 1. look in jar files related to dependencies > 2. find taglib files and other configuration files [each file type > needs its own parser] > 3. store tag uris that are discovered along with the associated jar > 4. check those tag uris vs what is in your code (keep in mind some may > be in config files you wrote, so gotta parse those too - more code to > write) > 5. output the list of jars (dependencies) which are not actually used > in code or config > > This is nontrivial, so no one has done it. I'm sure we'd take a > contribution if you did the work. > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Why is dependency:analyze lying to me?
> This may fall into the “How the hell is Maven supposed to know?” category, Yes, it most certainly does. > [WARNING] > org.springframework.security:spring-security-taglibs:jar:3.1.1.RELEASE:compile ... > Anyway, not sure if the plugin can be configured to detect these kind of > things, but a guy can dream, can’t he?? You would need to write code that performs the following tasks: 1. look in jar files related to dependencies 2. find taglib files and other configuration files [each file type needs its own parser] 3. store tag uris that are discovered along with the associated jar 4. check those tag uris vs what is in your code (keep in mind some may be in config files you wrote, so gotta parse those too - more code to write) 5. output the list of jars (dependencies) which are not actually used in code or config This is nontrivial, so no one has done it. I'm sure we'd take a contribution if you did the work. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Why is dependency:analyze lying to me?
Especially if you use Spring XML configuration, it's impossible for the Dependency Plugin to figure out you need this-or-that Spring jar. The best you can do, actually, is use the new Spring Java Config so that your configuration is code and thus able to be statically analyzed. On Thu, Feb 13, 2014 at 3:54 PM, laredotornado-3 wrote: > Hi, > > This may fall into the "How the hell is Maven supposed to know?" category, > but one of the dependencies that dependency:analyze lists when I run it on > my WAR project is > > [WARNING] Unused declared dependencies found: > ... > [WARNING] > > org.springframework.security:spring-security-taglibs:jar:3.1.1.RELEASE:compile > > However, when I comment this out of my pom, a few of my JSPs die with the > error > > org.apache.jasper.JasperException: The absolute uri: > http://www.springframework.org/security/tags cannot be resolved in either > web.xml or the jar files deployed with this application > > > org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:51) > > > org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:409) > > > org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:116) > > because the JSP includes this > > <%@ taglib prefix="sec" > uri="http://www.springframework.org/security/tags"%> > > Anyway, not sure if the plugin can be configured to detect these kind of > things, but a guy can dream, can't he?? > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Why-is-dependency-analyze-lying-to-me-tp5784108p5784691.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Cheers, Paul
Re: Why is dependency:analyze lying to me?
Hi, This may fall into the “How the hell is Maven supposed to know?” category, but one of the dependencies that dependency:analyze lists when I run it on my WAR project is [WARNING] Unused declared dependencies found: … [WARNING] org.springframework.security:spring-security-taglibs:jar:3.1.1.RELEASE:compile However, when I comment this out of my pom, a few of my JSPs die with the error org.apache.jasper.JasperException: The absolute uri: http://www.springframework.org/security/tags cannot be resolved in either web.xml or the jar files deployed with this application org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:51) org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:409) org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:116) because the JSP includes this <%@ taglib prefix="sec" uri="http://www.springframework.org/security/tags"%> Anyway, not sure if the plugin can be configured to detect these kind of things, but a guy can dream, can’t he?? -- View this message in context: http://maven.40175.n5.nabble.com/Why-is-dependency-analyze-lying-to-me-tp5784108p5784691.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Why is dependency:analyze lying to me?
On 13 February 2014 00:20, Mark H. Wood wrote: > On Wed, Feb 12, 2014 at 08:11:29AM +1030, Barrie Treloar wrote: > [snip] >> I think Maven is missing a scope, it needs to break up test into two >> phases; testCompile and testRuntime instead of having one scope which >> means both. [del] > Picky terminology tweak: Yes, my bad. I meant break that one scope into two scopes (not phases). Much like there are two scopes for compilation (compile and runtime), there needs to be two scopes for test (compile and runtime). - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Why is dependency:analyze lying to me?
On Wed, Feb 12, 2014 at 08:11:29AM +1030, Barrie Treloar wrote: [snip] > I think Maven is missing a scope, it needs to break up test into two > phases; testCompile and testRuntime instead of having one scope which > means both. > This means that the analyze code can't tell what stuff is needed for > tests at compile time and what is needed at runtime. Picky terminology tweak: I went off to check my memory because I was *sure* that Maven has a full set of test-* phases parallel to what we might call the "main" phases. It has. Then I came back here and saw that what you want is parallel *scopes* [test]Compile, [test]Runtime. Having sorted that (I hope), I think I agree with you. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. signature.asc Description: Digital signature
Re: Why is dependency:analyze lying to me?
I am so happy someone brought this up. I actually hit this issue several times but never got around to mentioning it. Please submit a JIRA issue! On Tue, Feb 11, 2014 at 3:41 PM, Barrie Treloar wrote: > On 12 February 2014 07:41, laredotornado-3 > wrote: > > Hi, > > > > I'm using Maven 3.1.1 on Mac 10.9.1. When I ran "mvn > dependency:analyze" on > > my project, I got results that included: > > > > [WARNING] Unused declared dependencies found: > > ... > > [WARNING]junit:junit:jar:4.11:test > > > > So I commented out the above junit dependency in my pom (declared like > so): > [del] > > java.lang.NoSuchFieldError: NULL > > at > org.junit.runners.ParentRunner.(ParentRunner.java:48) > > at > > > org.junit.runners.BlockJUnit4ClassRunner.(BlockJUnit4ClassRunner.java:58) > > at > > > org.springframework.test.context.junit4.SpringJUnit4ClassRunner.(SpringJUnit4ClassRunner.java:104) > > > > This isn't the only dependency that the analyze goal lists that wreaks > havoc > > when I comment it out. Is there another way to detect what dependencies > are > > truly not needed by my project? > > Unfortunately this stuff is not documented well enough in the plugin. > You're welcome to submit a patch! > > Have a look at > http://maven.apache.org/plugins/maven-dependency-plugin/faq.html#unused > > I think Maven is missing a scope, it needs to break up test into two > phases; testCompile and testRuntime instead of having one scope which > means both. > This means that the analyze code can't tell what stuff is needed for > tests at compile time and what is needed at runtime. > > If my memory serves me right, that would mean for your example that > Spring is a compile time dependency but junit would be a runtime > dependency. > Hence the incorrect "Unused declared dependencies found" error. > > I would manually ignore anything found in the test scope from the error > list. > I never found the time to go hacking the plugin to work better - i.e. > if it is test scope it really can't tell the difference between unused > dependencies and shouldn't report them. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Cheers, Paul
Re: Why is dependency:analyze lying to me?
On 12 February 2014 07:41, laredotornado-3 wrote: > Hi, > > I'm using Maven 3.1.1 on Mac 10.9.1. When I ran "mvn dependency:analyze" on > my project, I got results that included: > > [WARNING] Unused declared dependencies found: > ... > [WARNING]junit:junit:jar:4.11:test > > So I commented out the above junit dependency in my pom (declared like so): [del] > java.lang.NoSuchFieldError: NULL > at org.junit.runners.ParentRunner.(ParentRunner.java:48) > at > org.junit.runners.BlockJUnit4ClassRunner.(BlockJUnit4ClassRunner.java:58) > at > org.springframework.test.context.junit4.SpringJUnit4ClassRunner.(SpringJUnit4ClassRunner.java:104) > > This isn't the only dependency that the analyze goal lists that wreaks havoc > when I comment it out. Is there another way to detect what dependencies are > truly not needed by my project? Unfortunately this stuff is not documented well enough in the plugin. You're welcome to submit a patch! Have a look at http://maven.apache.org/plugins/maven-dependency-plugin/faq.html#unused I think Maven is missing a scope, it needs to break up test into two phases; testCompile and testRuntime instead of having one scope which means both. This means that the analyze code can't tell what stuff is needed for tests at compile time and what is needed at runtime. If my memory serves me right, that would mean for your example that Spring is a compile time dependency but junit would be a runtime dependency. Hence the incorrect "Unused declared dependencies found" error. I would manually ignore anything found in the test scope from the error list. I never found the time to go hacking the plugin to work better - i.e. if it is test scope it really can't tell the difference between unused dependencies and shouldn't report them. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Why is dependency:analyze lying to me?
Hi,
I’m using Maven 3.1.1 on Mac 10.9.1. When I ran “mvn dependency:analyze” on
my project, I got results that included:
[WARNING] Unused declared dependencies found:
…
[WARNING]junit:junit:jar:4.11:test
So I commented out the above junit dependency in my pom (declared like so):
junit
junit
${version.junit}
test
However, when I ran “mvm clean install” on my project, I got errors like
initializationError0(org.mainco.subco.core.SerializableTest) Time
elapsed:
0 sec <<< ERROR!
java.lang.NoSuchFieldError: NULL
at org.junit.runners.ParentRunner.(ParentRunner.java:48)
at
org.junit.runners.BlockJUnit4ClassRunner.(BlockJUnit4ClassRunner.java:58)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.(SpringJUnit4ClassRunner.java:104)
This isn’t the only dependency that the analyze goal lists that wreaks havoc
when I comment it out. Is there another way to detect what dependencies are
truly not needed by my project?
--
View this message in context:
http://maven.40175.n5.nabble.com/Why-is-dependency-analyze-lying-to-me-tp5784108.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: dependency:analyze seems to report spurious 'unused' jars
Well, for starters this plugin analyzes the binary code and not the source code. This means that reported unused declared dependencies might in fact be used when compiling the source code. Here's a few examples; * static constants - the compiler optimizes this by replacing the constant references with the actual value. Thus, analyzing the binary code there is no dependency any longer. * runtime dependencies - runtime dependencies normally don't have a direct code dependency so the plugin don't see this. The plugin should probably ignore runtime deps and I think I've seen some discussion/jira around adding this in the upcoming release, but I could be wrong. * Annotations with source retention - these annotation references are discarded by the compiler. There a more cases I'm sure. And there could of course also be bugs...:-) I think that what the plugin reports as "used undeclared dependencies" are always correct, but "unused declared dependencies" may be wrong. /Anders On Tue, Oct 23, 2012 at 8:05 PM, Benson Margulies wrote: > I've a situation in which 2.5.1 of m-d-p:analyze is reporting 'unused > declared dependencies' that are not unused, in fact, removing them and > running maven 3.0.4 has the immediate and dramatic effect of making > the compile fail. Is there something I don't understand here about > what those goals are trying to report? Should I try to make a test > case? > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
dependency:analyze seems to report spurious 'unused' jars
I've a situation in which 2.5.1 of m-d-p:analyze is reporting 'unused declared dependencies' that are not unused, in fact, removing them and running maven 3.0.4 has the immediate and dramatic effect of making the compile fail. Is there something I don't understand here about what those goals are trying to report? Should I try to make a test case? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: mvn dependency:analyze failed:Invalid signature file digest for Manifest main attributes
Yes, I did. It should be caused by that signed jars are changed. But my question is "whether there is a tool to identify which signed jars are changed?" Regards Simon Here is stack trace: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin: 2.1:analyze (default-cli) on project CoreAppFramework: Execution default-cli of goal org.apache.maven.plugins:maven-dependency-plugin:2.1:analyze failed: Invali d signature file digest for Manifest main attributes -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal o rg.apache.maven.plugins:maven-dependency-plugin:2.1:analyze (default-cli) on pro ject CoreAppFramework: Execution default-cli of goal org.apache.maven.plugins:ma ven-dependency-plugin:2.1:analyze failed: Invalid signature file digest for Mani fest main attributes at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:225) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje ct(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje ct(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBu ild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(Lifecycl eStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:611) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Laun cher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.jav a:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(La uncher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java: 352) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-c li of goal org.apache.maven.plugins:maven-dependency-plugin:2.1:analyze failed: Invalid signature file digest for Manifest main attributes at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Default BuildPluginManager.java:110) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:209) ... 19 more Caused by: java.lang.SecurityException: Invalid signature file digest for Manife st main attributes at sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVeri fier.java:241) at sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier .java:196) at java.util.jar.JarVerifier.processEntry(JarVerifier.java:266) at java.util.jar.JarVerifier.update(JarVerifier.java:220) at java.util.jar.JarInputStream.read(JarInputStream.java:193) at java.util.zip.ZipInputStream.closeEntry(ZipInputStream.java:111) at java.util.zip.ZipInputStream.getNextEntry(ZipInputStream.java:89) at java.util.jar.JarInputStream.getNextEntry(JarInputStream.java:129) at java.util.jar.JarInputStream.getNextJarEntry(JarInputStream.java:160) at org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.acc eptJar(ClassFileVisitorUtils.java:99) at org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.acc ept(ClassFileVisitorUtils.java:60) at org.apache.maven.shared.dependency.analyzer.DefaultClassAnalyzer.anal yze(DefaultClassAnalyzer.java:46) at org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyA nalyzer.buildArtifactClassMap(DefaultProjectDependencyAnalyzer.java:153) at org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyA nalyzer.analyze(DefaultProjectDependencyAnalyzer.java:72) at org.apache.maven.plugin.dependency.AbstractAnalyzeMojo.checkDependenc ies(AbstractAnalyzeMojo.java:168) at org.apache.maven.plugin.dependency.AbstractAnalyzeMojo.execute(Abstra ctAnalyzeMojo.java:152) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Default BuildPluginManager.java:101) ... 20 more -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: 2012年10月17日 12:00 To: Maven Users List Subject: Re: mvn depen
RE: mvn dependency:analyze failed:Invalid signature file digest for Manifest main attributes
Yes, you're right, but there are lots of dependency jars. Do you know whether there is a tool(maven plugin) to identify those signed changed jars? Regards Simon -Original Message- From: Martin Gainty [mailto:mgai...@hotmail.com] Sent: 2012年10月17日 10:41 To: users@maven.apache.org Subject: RE: mvn dependency:analyze failed:Invalid signature file digest for Manifest main attributes the manifest.mf contains a MD5-Digest which looks like Manifest-Version: 1.0 Name: bibparse-1.04/META-INF/MANIFEST.MF Digest-Algorithms: SHA MD5 SHA-Digest: +ZeuKiF1Qrq/ym6omfGMSD5tel0= MD5-Digest: uK1nT2MOzIU5HgaZzmZgHg==where the digest contained in MD-5 does not conform to the actual generated MD5 *for the jar * Martin Gainty __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. > From: yunfeng.w...@ebay.com > To: users@maven.apache.org > Subject: mvn dependency:analyze failed:Invalid signature file digest for > Manifest main attributes > Date: Wed, 17 Oct 2012 01:38:56 + > > Hi, >I'm trying to analyze my dependencies, but encountered "Invalid signature > file digest for Manifest main attributes" issue. > I know it should be caused by signed jar is changed. >But you know there are lot of dependency jars there. Is there a tool to > identify which signed jar is changed? > > Error log is here: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-dependency-plugin: > 2.1:analyze (default-cli) on project XXX: Execution default-cli of goal > org.apache.maven.plugins:maven-dependency-plugin:2.1:analyze failed: Invalid > signature file digest for Manifest main attributes -> [Help 1] > > Regards > Simon
Re: mvn dependency:analyze failed:Invalid signature file digest for Manifest main attributes
>But you know there are lot of dependency jars there. Is there a tool to > identify which signed jar is changed? Did you try adding -X for debug ouput? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: mvn dependency:analyze failed:Invalid signature file digest for Manifest main attributes
the manifest.mf contains a MD5-Digest which looks like Manifest-Version: 1.0 Name: bibparse-1.04/META-INF/MANIFEST.MF Digest-Algorithms: SHA MD5 SHA-Digest: +ZeuKiF1Qrq/ym6omfGMSD5tel0= MD5-Digest: uK1nT2MOzIU5HgaZzmZgHg==where the digest contained in MD-5 does not conform to the actual generated MD5 *for the jar * Martin Gainty __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. > From: yunfeng.w...@ebay.com > To: users@maven.apache.org > Subject: mvn dependency:analyze failed:Invalid signature file digest for > Manifest main attributes > Date: Wed, 17 Oct 2012 01:38:56 + > > Hi, >I'm trying to analyze my dependencies, but encountered "Invalid signature > file digest for Manifest main attributes" issue. > I know it should be caused by signed jar is changed. >But you know there are lot of dependency jars there. Is there a tool to > identify which signed jar is changed? > > Error log is here: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-dependency-plugin: > 2.1:analyze (default-cli) on project XXX: Execution default-cli of goal > org.apache.maven.plugins:maven-dependency-plugin:2.1:analyze failed: Invalid > signature file digest for Manifest main attributes -> [Help 1] > > Regards > Simon
mvn dependency:analyze failed:Invalid signature file digest for Manifest main attributes
Hi, I'm trying to analyze my dependencies, but encountered "Invalid signature file digest for Manifest main attributes" issue. I know it should be caused by signed jar is changed. But you know there are lot of dependency jars there. Is there a tool to identify which signed jar is changed? Error log is here: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin: 2.1:analyze (default-cli) on project XXX: Execution default-cli of goal org.apache.maven.plugins:maven-dependency-plugin:2.1:analyze failed: Invalid signature file digest for Manifest main attributes -> [Help 1] Regards Simon
Re: mvn dependency:analyze missing dependency?
You might be a victim of: http://jira.codehaus.org/browse/MDEP-124 -Olivier On Thu, 2009-06-18 at 21:18 -0400, David Weintraub wrote: > I am converting yet another Ant build to a Maven build. This time, I > purposefully laid out the directory tree, so when we do the > conversion, it would be much simpler. > > I've finally found all of my dependencies, added them into the > pom.xml, and got everything to compile and build the jar. (whether the > jar actually works is another question). > > I did a dependency:analyze, and got the following result: > > [INFO] [dependency:analyze] > [WARNING] Unused declared dependencies found: > [WARNING]com.wutka:jox:jar:1.16:compile > [WARNING]junit:junit:jar:3.8.1:test > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > > I know the junit would be because this jar has no tests. However ,the > com.wutka.jox is used in a particular program, and if I remove this > dependency from the pom.xml, the program won't compile. > > Why am I getting this message? > > -- > David Weintraub > qazw...@gmail.com > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
mvn dependency:analyze missing dependency?
I am converting yet another Ant build to a Maven build. This time, I purposefully laid out the directory tree, so when we do the conversion, it would be much simpler. I've finally found all of my dependencies, added them into the pom.xml, and got everything to compile and build the jar. (whether the jar actually works is another question). I did a dependency:analyze, and got the following result: [INFO] [dependency:analyze] [WARNING] Unused declared dependencies found: [WARNING]com.wutka:jox:jar:1.16:compile [WARNING]junit:junit:jar:3.8.1:test [INFO] [INFO] BUILD SUCCESSFUL [INFO] I know the junit would be because this jar has no tests. However ,the com.wutka.jox is used in a particular program, and if I remove this dependency from the pom.xml, the program won't compile. Why am I getting this message? -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: dependency:analyze-only and pom-only dependencies
This is because the analyze component is looking for classes in your dependency that are referenced in your classes. We should skip pom dependencies. On 9/21/08 8:16 PM, "Brett Porter" wrote: > This seems like a limitation in the plugin that you should file an issue for. > > Cheers, > Brett > > 2008/9/16 Barry Kaplan : >> >> We have setup some poms only for the purpose of declaring dependencies (eg, >> "unit-test" which depends junit, hamcrest, mockito, etc). Dependent projects >> declare the dependency using "pom". >> >> When I perform dependency:analyze-only on a project that depends on this pom >> "unit-test" is marked as "Unused declared dependencies found". >> >> Is there a way for maven to not get confused in this case? >> -- >> View this message in context: >> http://www.nabble.com/dependency%3Aanalyze-only-and-pom-only-dependencies-tp1 >> 9495150p19495150.html >> Sent from the Maven - Users mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: dependency:analyze-only and pom-only dependencies
This seems like a limitation in the plugin that you should file an issue for. Cheers, Brett 2008/9/16 Barry Kaplan <[EMAIL PROTECTED]>: > > We have setup some poms only for the purpose of declaring dependencies (eg, > "unit-test" which depends junit, hamcrest, mockito, etc). Dependent projects > declare the dependency using "pom". > > When I perform dependency:analyze-only on a project that depends on this pom > "unit-test" is marked as "Unused declared dependencies found". > > Is there a way for maven to not get confused in this case? > -- > View this message in context: > http://www.nabble.com/dependency%3Aanalyze-only-and-pom-only-dependencies-tp19495150p19495150.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Brett Porter Blog: http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependency:analyze
> I have been using the dependency:analyze successfully and I find it > works the way I expect (especially when migrating older code to Maven). > > That said, there are a couple of things to take into consideration: > > - Analysis is based on compiled .class files, so sometimes, a > compile-time dependency (on a constant defined in a JAR for instance) > can be optimized away by the compiler and cause the plugin to report a > false "Unused defined". > > - For Web apps, do not forget to compile the JSPs into .class files and > include those in the analysis to get the real picture. > Now that jsp precompile works, I re-tried "dependency:analyze". Nothing seems to have changed - it still claims I wouldn't need dependencies used by jsps. How can I include the precompiled jsps in the analysis? Thanks in advance, Stefanie -- Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games! http://games.entertainment.web.de/de/entertainment/games/free - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependency:analyze
Speaking Of Jasper plugins: how do you configure in differing jasper compilers? for instance lets say I was running eclipse how would i configure in jasper (jdt) compiler for eclipse??? Thanks Olivier Martin- - Original Message - From: "Olivier Dehon" <[EMAIL PROTECTED]> To: "Maven Users List" Sent: Saturday, March 01, 2008 8:24 PM Subject: Re: dependency:analyze > On Sat, 2008-03-01 at 19:41 +0100, [EMAIL PROTECTED] wrote: > > > - For Web apps, do not forget to compile the JSPs into .class files and > > > include those in the analysis to get the real picture. > > > > Oooh! Oookay! No, I didn't do that yet. That's still on my list to do. > > Which plugin to use for that? > > This one: http://mojo.codehaus.org/jspc-maven-plugin/usage.html ? > > > > I have had this one to work, even though it is very pedantic about the > JSP syntax (and I didn't take the time to investigate how to configure > it to be more lax...) > > > I haven't included it yet, as it seems to be complicated / weird - > > Nah, it is very straightforward. > > > If I got it right you need a "jspweb.xml"?! and you need to adjust your web.xml?! I would like to integrate new plugins with no adjustments to the application itself - for two reasons - > > a) political, "don't change the app while moving to mvn2" > > b) I neither like a requirement to have to touch (botch) an otherwise perfectly working application just to make it's deployment work > > > > If you have a web.xml, that should be enough. You do not need to touch > it (unless you want to start packaging the precompiled JSPs in your > final war and define the servlet-mappings generated by the plugin) > > > Any ideas / alternatives on this? > > > > p.s.: When I created class files from my jsps - do I have to adjust configuration so that dependency:analyze also analyzes those? Maybe you got some example? > > > > By default, the .class files it generates will be included in the > analysis. > > -Olivier > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependency:analyze
On Sat, 2008-03-01 at 19:41 +0100, [EMAIL PROTECTED] wrote: > > - For Web apps, do not forget to compile the JSPs into .class files and > > include those in the analysis to get the real picture. > > Oooh! Oookay! No, I didn't do that yet. That's still on my list to do. > Which plugin to use for that? > This one: http://mojo.codehaus.org/jspc-maven-plugin/usage.html ? > I have had this one to work, even though it is very pedantic about the JSP syntax (and I didn't take the time to investigate how to configure it to be more lax...) > I haven't included it yet, as it seems to be complicated / weird - Nah, it is very straightforward. > If I got it right you need a "jspweb.xml"?! and you need to adjust your > web.xml?! I would like to integrate new plugins with no adjustments to the > application itself - for two reasons - > a) political, "don't change the app while moving to mvn2" > b) I neither like a requirement to have to touch (botch) an otherwise > perfectly working application just to make it's deployment work > If you have a web.xml, that should be enough. You do not need to touch it (unless you want to start packaging the precompiled JSPs in your final war and define the servlet-mappings generated by the plugin) > Any ideas / alternatives on this? > > p.s.: When I created class files from my jsps - do I have to adjust > configuration so that dependency:analyze also analyzes those? Maybe you got > some example? > By default, the .class files it generates will be included in the analysis. -Olivier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependency:analyze
> - For Web apps, do not forget to compile the JSPs into .class files and > include those in the analysis to get the real picture. Oooh! Oookay! No, I didn't do that yet. That's still on my list to do. Which plugin to use for that? This one: http://mojo.codehaus.org/jspc-maven-plugin/usage.html ? I haven't included it yet, as it seems to be complicated / weird - If I got it right you need a "jspweb.xml"?! and you need to adjust your web.xml?! I would like to integrate new plugins with no adjustments to the application itself - for two reasons - a) political, "don't change the app while moving to mvn2" b) I neither like a requirement to have to touch (botch) an otherwise perfectly working application just to make it's deployment work Any ideas / alternatives on this? p.s.: When I created class files from my jsps - do I have to adjust configuration so that dependency:analyze also analyzes those? Maybe you got some example? Thanks, Stefanie -- Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games! http://games.entertainment.web.de/de/entertainment/games/free - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependency:analyze
I have been using the dependency:analyze successfully and I find it works the way I expect (especially when migrating older code to Maven). That said, there are a couple of things to take into consideration: - Analysis is based on compiled .class files, so sometimes, a compile-time dependency (on a constant defined in a JAR for instance) can be optimized away by the compiler and cause the plugin to report a false "Unused defined". - For Web apps, do not forget to compile the JSPs into .class files and include those in the analysis to get the real picture. Maybe you have a concrete example that shows the wrong behavior? -Olivier On Sat, 2008-03-01 at 17:48 +0100, [EMAIL PROTECTED] wrote: > Hi, > > I was recommended to use "dependency:analyze" by this list - > It's nice, but doesn't really work imho - > > Many dependencies that are def. required at runtime, it interprets as "not > required" - while others that are not required imho - it says the project > would need them. > > Any ideas why, and / or how to improve this? > > The way it's working, imho - its gives some nice information, but doesn't > seem to be very usefull > > > Thanks in advance, > > Stefanie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
dependency:analyze
Hi, I was recommended to use "dependency:analyze" by this list - It's nice, but doesn't really work imho - Many dependencies that are def. required at runtime, it interprets as "not required" - while others that are not required imho - it says the project would need them. Any ideas why, and / or how to improve this? The way it's working, imho - its gives some nice information, but doesn't seem to be very usefull Thanks in advance, Stefanie -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
dependency:analyze problem when using constants defined in an interface from a different module
Hi everyone,
I am using maven 2.0.7 with dependency plugin versoin 2.0-alpha-4.
I have 2 projects as seen in the end of the e-mail (This are some test files
to reproduce the problem)
My first project contains a single interface that defines a String constant.
My second project, uses the String constant from my first project.
I am having issues with the dependency:analyze goal...
In all my projects, i fail the build if there is either an unused declared
dependency or an used undeclared dependency using
org.apache.maven.plugins
maven-dependency-plugin
analyze
package
analyze
true
false
However, in the example below, i can not use the dependency plugin to
achieve this..
If i add the dependency from project 2 to project 1, i get:
[INFO] [dependency:analyze {execution: analyze}]
[INFO] Used declared dependencies:
[INFO]None
[INFO] Used undeclared dependencies:
[WARNING]None
[INFO] Unused declared dependencies:
[INFO]test:project1:jar:1.0-SNAPSHOT:compile
[WARNING] Potential problems discovered.
If i remove the supposedly unused dependency, then I get a compile error:
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
C:\ASSIA\development\maven_bug\project2\src\main\java\project2\NamesUser.java:[6
,24] package project1 does not exist
C:\ASSIA\development\maven_bug\project2\src\main\java\project2\NamesUser.java:[6
,24] package project1 does not exist
Any help would be greatly appreciated,
Regards,
Iker
Project 1:
pom.xml:
4.0.0
test
project1
jar
1.0-SNAPSHOT
1 source file:
package project1;
public interface Names {
/** name */
String NAME = "name";
}
Project 2:
4.0.0
test
project2
jar
1.0-SNAPSHOT
test
project1
1.0-SNAPSHOT
and 1 source file:
package project2;
public interface NamesUser {
String temp = project1.Names.NAME;
}
RE: Dependency analysis: dependency:analyze and dependency-analyzer:analyze
It was merged into the dependency plugin, so yes they are the same. -Original Message- From: Torsten Schlabach [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 25, 2007 10:29 AM To: users@maven.apache.org Subject: Dependency analysis: dependency:analyze and dependency-analyzer:analyze Hi! I am trying to analyze dependencies of a quite complex Maven project. Obviouosly there is http://maven.apache.org/plugins/maven-dependency-plugin/index.html But is the stuff mentioned here: http://www.mail-archive.com/users@maven.apache.org/msg61356.html the same? If not, what happened to the maven-dependency-analyzer-plugin? Regards, Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Dependency analysis: dependency:analyze and dependency-analyzer:analyze
Hi! I am trying to analyze dependencies of a quite complex Maven project. Obviouosly there is http://maven.apache.org/plugins/maven-dependency-plugin/index.html But is the stuff mentioned here: http://www.mail-archive.com/users@maven.apache.org/msg61356.html the same? If not, what happened to the maven-dependency-analyzer-plugin? Regards, Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependency:analyze incorrectly using excludes from DepMgtsection.
On 6/30/07, Brian E. Fox <[EMAIL PROTECTED]> wrote: >Ah, now I see what you mean. This does indeed look strange, especially >the wording of the message. On the other hand, it is just an INFO and >not a WARNING like the other problems found by the dependency:analyze >goal. I don't know if this behavior is intended. The message may be even >useful, because there may be something wrong in the project if a certain >dependency is excluded from one module but pulled in by another. If I >exclude it once it is very likely that I don't want it in my module at >all. Hi, this is how it was intended to work. It's intentionally looking for anything you excluded somewhere to see if it crept back in through another avenue. See here: http://jira.codehaus.org/browse/MDEP-76 Hmm. I'll have to think more on this. At the moment, I don't think excluding it from one plugin and then getting it from another is an error, but I'm not sure why I think that right now. I know EasyConf's plugin is junk. I am at home trying to remember stuff I should be checking at work... but I think EasyConf is not specifying provided for javax.servlet and thus I am excluding it for that reason. I would have to thought spring would be defining the right dependency details. I know I had to do something with log4j and one of the plugins a while ago because of a bug somewhere. I wonder if I should be overriding the dependency with the correct values instead of just excluding it... I will ponder this some more. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: dependency:analyze incorrectly using excludes from DepMgtsection.
>Ah, now I see what you mean. This does indeed look strange, especially >the wording of the message. On the other hand, it is just an INFO and >not a WARNING like the other problems found by the dependency:analyze >goal. I don't know if this behavior is intended. The message may be even >useful, because there may be something wrong in the project if a certain >dependency is excluded from one module but pulled in by another. If I >exclude it once it is very likely that I don't want it in my module at >all. Hi, this is how it was intended to work. It's intentionally looking for anything you excluded somewhere to see if it crept back in through another avenue. See here: http://jira.codehaus.org/browse/MDEP-76 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependency:analyze incorrectly using excludes from DepMgt section.
On Sat, 2007-06-30 at 11:12 +0930, Barrie Treloar wrote: > I'm excluding it because EasyConf specifies a different version and I > need to override it. Doesn't just pinning the version in dependencyManagement in such situations work? It should not be necessary to exclude the wrong version. However, in this particular case I think it's better to exclude it in both places. > > I have no idea why commons-logging wants javax.servlet. So I might try > excluding it as well. commons-logging pulls in all log implementations it supports. So if one does not want a lot of unnecessary jars the exclusions are required. javax.servlet is especially nasty since it is always provided by the AS and thus you never want it as a runtime dependency. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependency:analyze incorrectly using excludes from DepMgt section.
> I only excluded javax.servlet from EasyConf and not commons-logging, > so I shouldn't be getting this error. Ah, now I see what you mean. This does indeed look strange, especially the wording of the message. On the other hand, it is just an INFO and not a WARNING like the other problems found by the dependency:analyze goal. I don't know if this behavior is intended. The message may be even useful, because there may be something wrong in the project if a certain dependency is excluded from one module but pulled in by another. If I exclude it once it is very likely that I don't want it in my module at all. I'm excluding it because EasyConf specifies a different version and I need to override it. I have no idea why commons-logging wants javax.servlet. So I might try excluding it as well. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependency:analyze incorrectly using excludes from DepMgt section.
On Fri, 2007-06-29 at 21:26 +0930, Barrie Treloar wrote: > On 6/29/07, Heinrich Nirschl <[EMAIL PROTECTED]> wrote: > > On Thu, 2007-06-28 at 10:20 +0930, Barrie Treloar wrote: > > > When I run dependency:analyze on my module I get: > > > > > > [INFO] Found Resolved Dependency / DependencyManagement mismatches: > > > [INFO] Ignoring Direct Dependencies. > > > [INFO] javax.servlet:servlet-api:jar was excluded in DepMgt, but > > > version 2.3 has been found in the dependency tree. > > > > > > mvn site's Dependency Tree: > > > org.springframework:spring-beans:jar > > > * commons-logging:commons-logging:jar > > > o logkit:logkit:jar > > > o avalon-framework:avalon-framework:jar > > > o javax.servlet:servlet-api:jar > > > > > > > This is why servlet-api was pulled in. You seem to have a dependency on > > spring which in turn uses commons-logging and commons-logging brings in > > servlet-api. > > > > I always add the exclusions you specified for easyconf also to all the > > spring modules. > > Look more closely at the error > > > [INFO] javax.servlet:servlet-api:jar was excluded in DepMgt, but > > > version 2.3 has been found in the dependency tree. > > I only excluded javax.servlet from EasyConf and not commons-logging, > so I shouldn't be getting this error. Ah, now I see what you mean. This does indeed look strange, especially the wording of the message. On the other hand, it is just an INFO and not a WARNING like the other problems found by the dependency:analyze goal. I don't know if this behavior is intended. The message may be even useful, because there may be something wrong in the project if a certain dependency is excluded from one module but pulled in by another. If I exclude it once it is very likely that I don't want it in my module at all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependency:analyze incorrectly using excludes from DepMgt section.
On 6/29/07, Heinrich Nirschl <[EMAIL PROTECTED]> wrote: On Thu, 2007-06-28 at 10:20 +0930, Barrie Treloar wrote: > When I run dependency:analyze on my module I get: > > [INFO] Found Resolved Dependency / DependencyManagement mismatches: > [INFO] Ignoring Direct Dependencies. > [INFO] javax.servlet:servlet-api:jar was excluded in DepMgt, but > version 2.3 has been found in the dependency tree. > > mvn site's Dependency Tree: > org.springframework:spring-beans:jar > * commons-logging:commons-logging:jar > o logkit:logkit:jar > o avalon-framework:avalon-framework:jar > o javax.servlet:servlet-api:jar > This is why servlet-api was pulled in. You seem to have a dependency on spring which in turn uses commons-logging and commons-logging brings in servlet-api. I always add the exclusions you specified for easyconf also to all the spring modules. Look more closely at the error > [INFO] javax.servlet:servlet-api:jar was excluded in DepMgt, but > version 2.3 has been found in the dependency tree. I only excluded javax.servlet from EasyConf and not commons-logging, so I shouldn't be getting this error. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependency:analyze incorrectly using excludes from DepMgt section.
On Thu, 2007-06-28 at 10:20 +0930, Barrie Treloar wrote: > When I run dependency:analyze on my module I get: > > [INFO] Found Resolved Dependency / DependencyManagement mismatches: > [INFO] Ignoring Direct Dependencies. > [INFO] javax.servlet:servlet-api:jar was excluded in DepMgt, but > version 2.3 has been found in the dependency tree. > > mvn site's Dependency Tree: > org.springframework:spring-beans:jar > * commons-logging:commons-logging:jar > o logkit:logkit:jar > o avalon-framework:avalon-framework:jar > o javax.servlet:servlet-api:jar > This is why servlet-api was pulled in. You seem to have a dependency on spring which in turn uses commons-logging and commons-logging brings in servlet-api. I always add the exclusions you specified for easyconf also to all the spring modules. - Henry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
dependency:analyze incorrectly using excludes from DepMgt section.
When I run dependency:analyze on my module I get: [INFO] Found Resolved Dependency / DependencyManagement mismatches: [INFO] Ignoring Direct Dependencies. [INFO] javax.servlet:servlet-api:jar was excluded in DepMgt, but version 2.3 has been found in the dependency tree. mvn site's Dependency Tree: org.springframework:spring-beans:jar * commons-logging:commons-logging:jar o logkit:logkit:jar o avalon-framework:avalon-framework:jar o javax.servlet:servlet-api:jar The only definition of javax.servlet in parent pom easyconf easyconf 0.9.5 dom4j dom4j junit junit javax.servlet servlet-api So it looks like dependency:analyze has picked up the exclusion from easyconf and used it. I don't think it should be using this exclusion. Anyone else noticed similar results? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to get dependency:analyze to include .class files generated by jspc:compile?
Hi, How can I get the dependency:analyze goal to include the class files that result from the compilation of the JSPs in the actual analysis? Is there a configuration parameter to indicate additional target directories to look into? Am I missing something? Thanks in advance for sharing your experience with this. -Olivier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
