why does maven ear plugin runs the war:war (plugin goal) when I try to build the ear project from netbeans
my process:
I right click on the ear project (which has the war dependency listed) and first Clean and then right click on it and select Build with Dependencies. Then it builds the war again using the war:war and it takes time. even though there was no change in the war but will re create it again.
this is what it says :
------------------------------------------------------------------------ Building finweb 1.0-SNAPSHOT
------------------------------------------------------------------------ The POM for org.netbeans.external:jdom-1.0:jar:RELEASE71 is missing,
no dependency information available The POM for
com.ibm:com.ibm.mq:jar:6.0.2.5 is missing, no dependency information
available The POM for com.ibm:com.ibm.mqbind:jar:6.0.2.5 is missing,
no dependency information available The POM for
net.sf.saxon:saxon:jar:10.0-b19 is missing, no dependency information
available
[dependency:copy]
[resources:resources] Using 'UTF-8' encoding to copy filtered
resources. skip non existing resourceDirectory
C:\Beta\fin\finweb\src\main\resources
[compiler:compile] Nothing to compile - all classes are up to date
[resources:testResources] Using 'UTF-8' encoding to copy filtered
resources. skip non existing resourceDirectory
C:\Beta\fin\finweb\src\test\resources
[compiler:testCompile] Nothing to compile - all classes are up to date
[surefire:test] No tests to run. Surefire report directory:
C:\Beta\fin\finweb\target\surefire-reports
------------------------------------------------------- T E S T S
------------------------------------------------------- There are no tests to run.
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[war:war] Packaging webapp Assembling webapp [finweb] in
[C:\Beta\fin\finweb\target\finweb-1.0-SNAPSHOT] Processing war
project Copying webapp resources
[C:\Beta\fin\finweb\src\main\webapp] Webapp assembled in [109467
msecs] Building war:
C:\Beta\fin\finweb\target\finweb-1.0-SNAPSHOT.war WEB-INF\web.xml
already added, skipping
[install:install] Installing
C:\Beta\fin\finweb\target\finweb-1.0-SNAPSHOT.war to C:\Documents
and
Settings.m2\repository\com\comp\finweb\1.0-SNAPSHOT\finweb-1.0-SNAPSHOT.war
Installing C:\Beta\fin\finweb\pom.xml to C:\Documents and
Settings\5510041.m2\repository\com\comp\finweb\1.0-SNAPSHOT\finweb-1.0-SNAPSHOT.pom
So if there is nothing to compile why would it build a war again if it was already made and there are no changes. is this the default behaviour, looking at compile : compile when it doesnt compile if there is nothing needed then why does war:war does it, it shud be intelligent enuff to do it right?
pls correct me if I am wrong
Thanks in advance..
Syed.
This may be considered as workaround.
Following configs will speed up your build time.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.4</version>
<configuration>
<useCache>true</useCache>
<recompressZippedFiles>false</recompressZippedFiles>
</configuration>
</plugin>
Reference :https://maven.apache.org/plugins/maven-war-plugin/war-mojo.html
Also am looking forward for easy way to skip war:war phase from maven default build lifecycle.
Your concern can be understood. But in principle maven-war-plugin does not know that the resulting WAR artifact will be identical to one which was build a minute ago because:
You might define MANIFEST entry that contains the current build time.
You might enable different profile, which will change the picture completely.
Other plugins (like maven-ant-plugin, maven-dependency-plugin) might add something to target directory depending on some changing conditions (e.g. property from command line).
So it is safer to rebuild war each time. On modern platforms this is really negligible.
Related
I have created a Jenkins job which performs a SONAR QUBE analysis.
I have added the SONAR scan as a generic build step.
I have not made any modifications to the project to enable the SONAR integration since the project should not have to care about SONAR. (i.e. no changes to POM.xml and no properties file(s) added)
My SONAR integration is working, without any mods necessary to the project, which is great.
However, it is a multi module project and now I want to exclude one of the modules from the scan, since this module contains auto generated code.
Here are the Maven commands that I’m using to trigger the SONAR scan in Jenkins:
sonar:sonar
-Dsonar:host.url=http://url.com:9000/sonar
-Dsonar.login=myusername
-Dsonar.password=mypassword
Here is my project structure:
root
Project A
Project B
Project C
I want to exclude ProjectB from the scan.
I have tried -Dsonar.exclusions=/ProjectB and it did not work.
Here is an excerpt from the log:
[INFO] ------------- Scan Project B
[INFO] Base dir: /workspace/jenkins/…/workspace/CI-JOB-NAME/projectB
[INFO] Working dir: /workspace/jenkins/…/workspace/CI-JOB-NAME/projectB/target/sonar
[INFO] Source paths: pom.xml, src/main/java
[INFO] Binary dirs: target/classes
[INFO] Source encoding: UTF-8, default locale: en_US
[INFO] Index files
[INFO] Excluded sources:
[INFO] /projectB
[INFO] 44 files indexed
[INFO] 0 files ignored because of inclusion/exclusion patterns
As shown in the log, the excluded sources property is set but not working since it says 0 files ignored...
Question: How do I exclude everything inside the project B directory from the scan?
(Preferably using a command in the Jenkins job and not adding any properties files or other modifications to the project itself)
Is the “Excluded sources path” relative to the “Base dir” path or the Root??
Should I define the exclusion path as an absolute path?
The documentation has a dedicated section for this.
The options that seem suitable for your case:
use build profiles to exclude some module (like for integration tests)
use Advanced Reactor Options (such as -pl). For example mvn sonar:sonar -pl !module2
For example using this last one, you could do:
sonar:sonar -pl "!projectB"
-Dsonar:host.url=http://url.com:9000/sonar
-Dsonar.login=myusername
-Dsonar.password=mypassword
Is the “Excluded sources path” relative to the “Base dir” path or the Root?? Should I define the exclusion path as an absolute path?
According to the documentation on exclusions,
patterns are relative to the base directory, so not absolute paths.
In any case, I don't think this option is useful in your case,
because in a multi-module maven project,
the files of a sub-module are indexed with the path relative to the module's base directory. So a pattern like projectB/** will not match anything, as projectB is not part of the paths used. If you have some unique package name in the module, let's say someuniquepackage, located at src/main/java/someuniquepackage, then the pattern src/main/java/someuniquepackage/** would work.
In anycase, I recommend the -pl option above, or using Maven's profile feature.
I was doing some testing using Maven and realized that I can execute the findbugs goal of the Findbugs plugin without adding the plugin to the POM file. On the other hand, when I needed to run the run goal of the Jetty plugin, I was forced to add the plugin to the POM file or the build failed.
Why Jetty needed configuration in the POM while Findbugs didn't?
How does Maven know which Findbugs to execute (suppose we have to plugins with the same name but different group id)?
When I run the first command the build is successful without any changes in POM file:
mvn findbugs:findbugs
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building module-mytest 1.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- findbugs-maven-plugin:3.0.4:findbugs (default-cli) # module-mytest ---
[INFO] Fork Value is true
[java] Warnings generated: 6
[INFO] Done FindBugs Analysis....
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 24.165s
[INFO] Finished at: Sun Oct 23 18:40:26 WEST 2016
[INFO] Final Memory: 21M/111M
[INFO] -----------------------------------------------------------------------
But when I run the second I get this:
mvn jetty:run
[INFO] Scanning for projects...
Downloading: http://repo.maven.apache.org/maven2/org/codehaus/mojo/maven-metadata.xml
Downloading: http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-metadata.xml
Downloaded: http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-metadata.xml (13 KB at 30.0 KB/sec)
Downloaded: http://repo.maven.apache.org/maven2/org/codehaus/mojo/maven-metadata.xml (20 KB at 41.0 KB/sec)
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.129s
[INFO] Finished at: Sun Oct 23 18:43:27 WEST 2016
[INFO] Final Memory: 12M/104M
[INFO] ------------------------------------------------------------------------
[ERROR] No plugin found for prefix 'jetty' in the current project and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (/home/hp-pc/.m2/repository), central (http://repo.maven.apache.org/maven2)] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/NoPluginFoundForPrefixException
So in order to pass the build I needed to add the following to the pom file:
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.2.11.v20150529</version>
</plugin>
What is a prefix and why do we need it?
You just encountered the Plugin Prefix Resolution of Maven. This is a feature which enables the user to invoke goals of a specific Maven plugin, by using its prefix. When you invoke directly a goal on the command-line, you could use the fully-featured form of:
mvn my.plugin.groupId:foo-maven-plugin:1.0.0:bar
This would invoke the goal bar of the Foo Maven plugin having the coordinates my.plugin.groupId:foo-maven-plugin:1.0.0 (in the form of groupId:artifactId:version). It works well, but it is a bit verbose. It would be nice to invoke this goal in a simpler manner, without specifying all those coordinates. Maven makes this possible by assigning prefixes to plugins, so that you can refer to this prefix instead of the whole coordinates, with:
mvn foo:bar
^^^ ^^^
| |
prefix |
|
goal
How is this prefix determined?
You can define a prefix for each Maven plugin. This corresponds to a simple name used to identify it:
The conventional artifact ID formats to use are:
maven-${prefix}-plugin - for official plugins maintained by the Apache Maven team itself (you must not use this naming pattern for your plugin, see this note for more informations)
${prefix}-maven-plugin - for plugins from other sources
If your plugin's artifactId fits this pattern, Maven will automatically map your plugin to the correct prefix in the metadata stored within your plugin's groupId path on the repository.
Put another way, if your plugin's artifact id is named foo-maven-plugin, Maven will automatically assign it a prefix of foo. If you don't want this default assignment, you can still configure your own with the help of the maven-plugin-plugin and its goalPrefix parameter.
How does Maven map prefixes to plugins?
In the command
mvn foo:bar
Maven must have a way to deduce that foo actually means my.plugin.groupId:foo-maven-plugin. In the settings.xml file, you can add plugin groups, in the form of:
<pluginGroups>
<pluginGroup>org.mortbay.jetty</pluginGroup>
</pluginGroups>
What this does, is telling Maven which group id it is supposed to consider when you're using a prefix in a command. By default, and in addition to the groups specified in the settings, Maven also searches the group ids org.apache.maven.plugins and org.codehaus.mojo. It searches those default ones after the ones you configured in the settings. Therefore, with the configuration above, and a command of mvn foo:bar, Maven will look for a plugin having a prefix of foo inside the group id org.mortbay.jetty, org.apache.maven.plugins and org.codehaus.mojo.
The second step is how that search is actually performed. Maven will download metadata files (or look them into your local repository if they are already downloaded), called maven-metadata.xml, from each remote repositories at those group ids. If we take the example where the only remote repository we have is Maven Central, Maven will first download http://repo1.maven.org/maven2/org/mortbay/jetty/maven-metadata.xml, and look inside this file if we have something mapping foo. Notice how the group id was transformed into a directory structure in the remote repository. The structure of this metadata file is:
<metadata>
<plugins>
<plugin>
<name>Some Awesome Maven Plugin</name>
<prefix>somePrefix</prefix>
<artifactId>some-maven-plugin</artifactId>
</plugin>
</plugins>
</metadata>
If none of the <plugin> section contain a <prefix> that is equal to the one we specified (foo), Maven will continue with the next group id, hitting http://repo1.maven.org/maven2/org/codehaus/mojo/maven-metadata.xml. Again, if none are found, Maven will finally hit http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-metadata.xml (notice the Downloading: logs in your mvn jetty:run command, exactly fetching those last two files). If none are still found, there is nothing Maven can do for you anymore, and it will error:
[ERROR] No plugin found for prefix 'foo' in the current project and in the plugin groups [org.mortbay.jetty, org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (.../.m2/repository), central (http://repo.maven.apache.org/maven2)] -> [Help 1]
This is the error you have here. However, if one match was made during this search, then Maven can deduce the <artifactId> to use.
It now means it has the group id, and the artifact id. The final piece of the puzzle is the version
Which version is going to be used?
Maven will take the latest one available, unless explicitly configured in the POM (see next section). All possible versions are retrieved by fetching another metadata file, still called maven-metadata.xml, but this time living alongside the artifact id folder in the repository (contrary to the ones above, where it was alongside the group id). Taking the example of the Maven Clean plugin (whose group id and artifact id would be found with the above mechanism and a command of mvn clean:clean), the maven-metadata.xml looks like:
<metadata>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-clean-plugin</artifactId>
<versioning>
<latest>3.0.0</latest>
<release>3.0.0</release>
<versions>
<version>2.0-beta-1</version>
<version>2.0-rc1</version>
<version>2.0</version>
<version>2.1</version>
<!-- more versions -->
<version>3.0.0</version>
</versions>
<lastUpdated>20151022205339</lastUpdated>
</versioning>
</metadata>
Maven will select as version the <release> version, which represents the latest release version of the plugin. If that tag isn't there, it will select <latest> which represent the latest version of the plugin, release or snapshot. It can happen that both tags are not there, in which case, Maven will select the first release, or the first snapshot for lack of a release, of the list of <version> elements.
If that still fails, there is nothing Maven can do for you anymore, the version couldn't be deduced and it errors. This isn't very likely to happen though. We now have gathered the group id, the artifact id, and the version; time to finally invoke the bar goal of our plugin.
What's the issue with my configuration?
As said above, Maven looks in certain pre-defined group ids inside the active remote repositories to look for matches with a given prefix. With the command
mvn findbugs:findbugs
Maven starts the search with the findbugs prefix. Since our configuration does not have any <pluginGroup> in our settings, Maven looks into org.codehaus.mojo and org.apache.maven.plugins group id for a prefix match.
And it does find one: Findbugs Maven Plugin is published under the org.codehaus.mojo group id; indeed, you can find it in the maven-metadata.xml:
<plugin>
<name>FindBugs Maven Plugin</name>
<prefix>findbugs</prefix>
<artifactId>findbugs-maven-plugin</artifactId>
</plugin>
And you can also find the version that is going to be used by peeking into the maven-metadata.xml file under the findbugs-maven-plugin just deduced (3.0.4 at the time of this writing; and notice how it exactly matches the version in the mvn findbugs:findbugs logs of your question). So the resolution succeeded, and then Maven can continue to invoke the findbugs goal of this plugin.
The second example is the command
mvn jetty:run
As before, the same resolution steps happen, but, in this case, you'll find out that the prefix <jetty> does not appear in any of the maven-metadata.xml for the group ids org.codehaus.mojo and org.apache.maven.plugins. So the resolution fails, and Maven returns the error that you have.
But we've seen how to make it work! We can add a <pluginGroup> inside our settings, so that this group id can also be searched during resolution. The Jetty Maven Plugin is published under the group id org.eclipse.jetty, and if we peek into the corresponding maven-metadata.xml in Maven Central, you'll see that <prefix>jetty</prefix> is there. So the fix is simple: just define this new group id to search inside the settings:
<pluginGroups>
<pluginGroup>org.eclipse.jetty</pluginGroup>
</pluginGroups>
Now, Maven will also look into this group id, and match the jetty prefix to the org.eclipse.jetty:jetty-maven-plugin successfully.
How can I use a specific version? Or, I don't want to modify my settings!
Of course, all of this resolution can be side-tracked if you define the plugin explicitly in your POM, which is the other solution you found:
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.2.11.v20150529</version>
</plugin>
and use
mvn jetty:run
If you configure the plugin directly in the POM, the prefix resolution still happens, but it is a bit masked: Maven will download the plugin from the configured remote repositories, and will download and install all metadata files along the way, including the maven-metadata.xml containing the mapping for the prefix jetty. So since it downloads it automatically, the search always succeeds.
Note also that since the plugin was defined in the POM, you wouldn't need any <pluginGroup> in the settings: the group id was written in the POM. Furthermore, it makes sure that the version 9.2.11.v20150529 is going to be used, instead of the latest.
I am trying to make sense of all the dependency thing in maven multiple module projects. As a starting point I used appfuse to create a new spring mvc multi-module project. It initially has web and core modules.
I found the knowledge of deploying this project. But when I get an error. I am confused of where to add a dependency or a plugin always. I would like to clarify with the following issue.
I created a appfuse mvc multimodule project. I maven installed the core and then maven jetty7:run on web (initially I ran mvn install on root folder and then I tied to mvn tomcat:run on the same folder. But it has to be done as below.
mvn install on core folder
mvn tomcat7:run on web folder
I initially got an error like missing prefix "Tomcat7". I resolved it by adding the following plugin to the pom in web.
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.0</version>
</plugin>
And that error was resolved. But I was unsure about that because I can add the plugin to the parent pom. Then I ran again mvn tomcat7:run on web file and now I am getting the following error.
[INFO] >>> tomcat7-maven-plugin:2.0:run (default-cli) # test-web >>>
[WARNING] The POM for org.aspectj:aspectjweaver:jar:1.8.0.M1 is missing, no depe
ndency information available
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
I am not sure where to add the dependency to which pom. I would like know some basics of how the poms can work together to do the installation. For example, There is also a parent pom. But I am not doing a mvn install or anything on the parent pom. I am going to the core and do a mvn install and then go to the web and do a mvn tomcat7:run
I this case how the parent pom contribute to the installation and ruining process? and how should I resolve the above warning and resolve the error.
Some informative answer is very much appreciated. Thanks
You should add the Tomcat plugin to the web project as it will only work in a project that's type "war". There should already be a jetty plugin configured, so "mvn jetty:run" should work from the web folder.
This is an existing project that builds and deploys just fine using Intellij + AS7. I want to build and deploy using Netbeans 7.3.1 so I created a new Maven project in NetBeans, selecting the "import the project using the Maven pom.xml files" option. NetBeans recognized the modules and used Maven to build the project successfully. Very nice.
Webapp assembled in [931 msecs]
Building war: G:\Patrac_Netbeans\Patrac-web\target\Patrac-web-1.0.war
Next, I started JBoss using NetBeans' Services panel. Next, I clicked the Run Project button, expecting deployment to occur, but NetBeans only rebuilt the project again. And then I remembered configuring Intellij to build & deploy using the target directory. I don't see a way to do this in NetBeans. So, how to set up the deployment using NetBeans?
UPDATE 8/20/2013:
The deployment of the EJB- and WAR modules work. Here's the output when deploying the EJB:
cd G:\Patrac_Netbeans\Patrac-ejb; "JAVA_HOME=C:\Program Files\Java\jdk1.7.0_25" "\"G:\Program Files\NetBeans 7.3.1\java\maven\bin\mvn.bat\"" -Dnetbeans.deploy=true package
Scanning for projects...
Building Patrac EJB module 1.0
...
BUILD SUCCESS
Total time: 8.251s
Finished at: Tue Aug 20 14:33:38 EDT 2013
Final Memory: 22M/364M
NetBeans: Deploying on JBoss Application Server
profile mode: false
debug mode: false
force redeploy: true
Distributing G:\Patrac_Netbeans\Patrac-ejb\target\Patrac-ejb.jar to [org.jboss.as.ee.deployment.spi.DeploymentManagerTarget#45fbf23c]
Deploying G:\Patrac_Netbeans\Patrac-ejb\target\Patrac-ejb.jar
However when I attempt to run the whole application NetBeans doesn't deploy:
cd G:\Patrac_Netbeans; "JAVA_HOME=C:\Program Files\Java\jdk1.7.0_25" "\"G:\Program Files\NetBeans 7.3.1\java\maven\bin\mvn.bat\"" -Dnetbeans.deploy=true package
Scanning for projects...
Reactor Build Order:
PATRAC
Patrac EJB module
Patrac Web module
Building PATRAC 1.0-SNAPSHOT
...
Building Patrac EJB module 1.0
...
Building Patrac Web module 1.0
...
[war:war]
Packaging webapp
Assembling webapp [Patrac-web] in [G:\Patrac_Netbeans\Patrac-web\target\Patrac.war]
Processing war project
Copying webapp resources [G:\Patrac_Netbeans\Patrac-web\src\main\webapp]
Webapp assembled in [557 msecs]
Building war: G:\Patrac_Netbeans\Patrac-web\target\Patrac-web-1.0.war
Reactor Summary:
PATRAC - Physician Assistant Tracking ............. SUCCESS [0.043s]
Patrac EJB module ................................. SUCCESS [8.100s]
Patrac Web module ................................. SUCCESS [2.324s]
BUILD SUCCESS
Total time: 10.882s
Finished at: Tue Aug 20 14:17:34 EDT 2013
Final Memory: 25M/366M
Why in the world does NetBeans not deploy? Perhaps the problem is that it doesn't know where the assembled WAR is located? Looking at the output, it runs Maven from G:\Patrac_Netbeans, which is where the root POM is located. However the assembled WAR is located in G:\Patrac_Netbeans\Patrac-web\target\Patrac.war.
UPDATE 8/21/2013:
Fyi the plugin config was as follows:
<plugin>
<groupId>org.jboss.as.plugins</groupId>
<artifactId>jboss-as-maven-plugin</artifactId>
<version>7.4.Final</version>
</plugin>
As #happymeal correctly pointed out (see his comment, below), by simply looking at Maven's output the plugin was not running. Thanks to #James R. Perkins I realized there were actually two plugins: jboss-maven-plugin and jboss-as-maven-plugin and because I was using the latter plugin I was using the wrong goal: jboss:deploy instead of jboss-as:deploy. Correcting this mistake and rerunning the project in Netbeans the following error occurred:
Caused by: java.io.FileNotFoundException: G:\Patrac_Netbeans\target\Patrac-1.0-SNAPSHOT.maven-project (The system cannot find the path specified)
Next, I added some configuration parameters that ultimately solved the problem:
<plugin>
<groupId>org.jboss.as.plugins</groupId>
<artifactId>jboss-as-maven-plugin</artifactId>
<version>7.4.Final</version>
<configuration>
<force>true</force>
<targetDir>G:\Patrac_Netbeans\Patrac-web\target</targetDir>
<filename>Patrac-web-1.0.war</filename>
</configuration>
</plugin>
Problem solved!
the default maven goal for the "Run Project" button in netbeans is package. this goal builds the project but does not deploy your app.
you can change this by:
right-clicking on your project and go to properties.
under the categories panel, select actions.
select the "Run Project" action and edit the "Execute Goals" textbox (e.g. jboss:start).
note that you will need the jboss maven plugin.
When I build my project, I get these warnings:
[INFO] ------------------------------------------------------------------------
[INFO] Building XXX
[INFO] ------------------------------------------------------------------------
[WARNING] The POM for org.eclipse.update:org.eclipse.update.configurator:jar:3.2.0 is missing, no dependency information available
[WARNING] The POM for org.eclipse.emf:org.eclipse.emf.ecore:jar:2.3.2 is missing, no dependency information available
[WARNING] The POM for com.ibm.icu:com.ibm.icu:jar:3.4.4 is missing, no dependency information available
In my build, I overwrite the versions of these dependencies and the build itself succeeds.
What is the fastest way to fix the warnings?
Edit: What is the fastest way to locate the POMs which contain these versions?
Note: I have 7000 POMs in my local repo.
try the analyze tools from the dependency-plugin
especially the mvn dependency:analyze-dep-mgt
A few things that might help:
mvn dependency:tree -Dverbose=true can spit out unused duplicates/versions. Wasn't enough in my case, however, for some reason it didn't show the offending jar's listed [?]. It also doesn't show the ommitted jar's descendants, which may or may not be useful.
ref: http://jira.codehaus.org/browse/MDEP-123
Intellij can list what it thinks are offending pom's and paths (open the pom.xml file, hover over the underlined "project":
Unfortunately none of these was enough for me, either.
Then I noticed that if you delete the offending directory from your ~/.m2/repository, it will be downloaded again and basically empty. So I think what this error message can sometimes mean is "your nexus lists a version that it doesn't actually have available for download." It appears that maven by default, if you request for instance commons-logging 1.1.1, will attempt to download the pom's for all known versions of common-logging, then, in my case, it spit out that warning but it was benign. Phew!
So in truth, none of your projects might point to the warned of bad pom (or bad version, etc.) Except nexus' metadata index.
You could use dependency:tree to see what pom references the one you're missing