Maven IDEA plugin generating incorrect references in .ipr file in multi-module project

Is there a bug in the maven IDEA plugin when working with multi-module files?
I normally do most of my command-line work in the Cygwin environment, and
have not experienced this problem on my previous project, which was a
single-module project.

ERROR in parent project file:

- generated this when running mvn idea:idea under cygwin
- trying to open the project file results in error dialog box:
"Cannot load module file
'C:\work\Fads\C:\work\Fads\FeedProcessor\FeedProcessor.iml':
File C:\work\Fads\C:\work\Fads\FeedProcessor\FeedProcessor.iml does not exist.
Would you like to remove the module from the project?"

<modules>
<module fileurl="file://$PROJECT_DIR$/C:/work/FeedsProject/packaging/FeedsProject.iml"
filepath="$PROJECT_DIR$/C:/work/FeedsProject/packaging/FeedsProject.iml"
/>
<module fileurl="file://$PROJECT_DIR$/FadsParent.iml"
filepath="$PROJECT_DIR$/FadsParent.iml" />
<module fileurl="file://$PROJECT_DIR$/C:/work/FeedsProject/FeedProcessor/FeedProcessor.iml"
filepath="$PROJECT_DIR$/C:/work/FeedsProject/FeedProcessor/FeedProcessor.iml"
/>
<module fileurl="file://$PROJECT_DIR$/C:/work/FeedsProject/FileService/FileService.iml"
filepath="$PROJECT_DIR$/C:/work/FeedsProject/FileService/FileService.iml"
/>
</modules>

- the fix is to generate the IDEA project file under DOS - mvn idea:idea
- this file is correct.

<modules>
<module fileurl="file://$PROJECT_DIR$/packaging/FeedsProject.iml"
filepath="$PROJECT_DIR$/packaging/FeedsProject.iml" />
<module fileurl="file://$PROJECT_DIR$/FadsParent.iml"
filepath="$PROJECT_DIR$/FadsParent.iml" />
<module fileurl="file://$PROJECT_DIR$/FeedProcessor/FeedProcessor.iml"
filepath="$PROJECT_DIR$/FeedProcessor/FeedProcessor.iml" />
<module fileurl="file://$PROJECT_DIR$/FileService/FileService.iml"
filepath="$PROJECT_DIR$/FileService/FileService.iml" />
</modules>

OutOfMemory error when using Findbugs plugin in Maven? Set the Maven heap size via MAVEN_OPTS

I was doing a "mvn site" and I got an OutOfMemory error at the stage
where it's using the Findbugs plugin:

[INFO] Generating "FindBugs Report" report.
[INFO] No effort provided, using default effort.
[INFO] Using FindBugs Version: 1.2.0
[INFO] No threshold provided, using default threshold.
[INFO] Debugging is Off
[INFO] No bug include filter.
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Java heap space
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.OutOfMemoryError: Java heap space
at edu.umd.cs.findbugs.ba.vna.ValueNumberFrame.getUpdateableAvailableLoadMap(ValueNumberFrame.java:409)
at edu.umd.cs.findbugs.ba.vna.ValueNumberFrame.copyFrom(ValueNumberFrame.java:285)
at edu.umd.cs.findbugs.ba.FrameDataflowAnalysis.copy(FrameDataflowAnalysis.java:38)
at edu.umd.cs.findbugs.ba.vna.ValueNumberAnalysis.trans

After a bit of research, I set this variable to give enough memory to
Maven, and it fixed the problem. Obviously, change the Xmx value
depending on how much RAM you have to spare.

MAVEN_OPTS="-Xmx1024m -Xms128m -XX:MaxPermSize=512m"

Other posts have mentioned that it's actually setting a MaxPermSize
higher than the default value (32m) that makes the difference. So
let's test it by just setting the first two values:

MAVEN_OPTS="-Xmx1024m -Xms128m"

Actually, it works!

INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 minute 11 seconds

Other people have recommended setting the plugin property
"maven.findbugs.jvmargs" but I have not tried this out yet. Now in my
pom.xml, I currently have:

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>1.1.1</version>
</plugin>

Which isn't actually the latest version anymore. Maybe the newest
version of the plugin - 1.2 has fixed it.. Let's change it to:

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>1.2</version>
</plugin>

But this time, let's NOT have anything in MAVEN_OPTS. Let's see if the
newer version can do it with the default java settings. Now run mvn
site again.

(Long delay follows). Oh great, more jars to download. WTF? castor?
openejb? xstream? Hardly a build goes by where I don't get yet another
surprise download due to transitive dependencies. Am glad we have
Artifactory set up at work, so only one person has to suffer the
delays of downloading each new jar file.

No dice. OutOfMemoryError again. Let's set our heap to a smaller
figure, compared to before, see if that's enough.

MAVEN_OPTS="-Xmx256m -Xms128m"

Works!

I think this last one can be a safe starting value to use if you ever
run into the OutOfMemory error Findbugs from inside maven. I was
surprised to find out that the default heap is only 32m when JVM is in
client mode, and 64m when in server mode. See here:
http://www.unixville.com/~moazam/stories/2004/05/17/maxpermsizeAndHowItRelatesToTheOverallHeap.html

Maven settings.xml that uses Artifactory, and restricts snapshot repository use

Hopefully this information is useful for other people who have Maven
projects but have to use other libraries and Maven plugins that are
still in the pre-release stage.

We are using Artifactory at work as a local repository proxy for Maven.

We also have a project that makes use of some snapshot libraries for
the CXF project, which is currently under incubation in Apache.

Previously, we were just using a <mirrors> but this resulted in Maven
getting its metadata settings both from the central repository and the
snapshot locations. We ended up getting snapshots of Maven plugins
that we never really wanted, as Maven would get plugin metadata from
both the repository types, and of course, the latest version would be
the snapshot ones.

To remedy this, we had to change settings.xml so that the only time
the Apache snapshot plugin repositories are used is in the projects
that require the CXF plugin and associated dependencies. The important
thing is to make sure the id element in the repository settings match
the repository setting id in the project pom.xml. The pom.xml settings
can still point to the live, non-proxied repository, but Maven will
first look at the id in that pom file and see if there is an entry
with the same id in the settings.xml

<settings>

<!-- uncomment this section and comment out the profiles section if
the Artifactory (local maven repository) is broken -->

<!--

<proxies>
<proxy>
<active>true</active>
<protocol>http</protocol>
<host>company.proxy</host>
<port>8080</port>
</proxy>
</proxies>
-->

<profiles>
<profile>
<id>default</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>

<repositories>
<repository>
<id>central</id>
<url>http://internal.company.proxy:7070/artifactory/repo1
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
<repository>
<id>snapshots</id>

<url>http://internal.company.proxy:7070/artifactory/snapshots-only
<releases>
<enabled>false</enabled>
</releases>
</repository>

<repository>
<id>everything-else</id>

<url>http://internal.company.proxy:7070/artifactory/releases
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>

<!-- used by SomeWebService/pom.xml The id here
*must* match what's in the pom file -->
<repository>
<id>apache.org</id>

<url>http://internal.company.proxy:7070/artifactory/apache-m2-snapshots
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>

<!-- used by SomeWebService/pom.xml The id here
*must* match what's in the pom file -->
<repository>
<id>apache.incubating.releases</id>

<url>http://internal.company.proxy:7070/artifactory/apache-m2-incubating
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>

</repositories>

<pluginRepositories>

<pluginRepository>
<id>central</id>
<url>http://internal.company.proxy:7070/artifactory/repo1
<snapshots>
<enabled>false</enabled>
</snapshots>
</pluginRepository>
<pluginRepository>
<id>snapshots</id>

<url>http://internal.company.proxy:7070/artifactory/snapshots-only
<releases>
<enabled>true</enabled>
</releases>
</pluginRepository>

<!-- used by SomeWebService/pom.xml The id here
*must* match what's in the pom file -->
<pluginRepository>
<id>apache-plugin-incubating</id>

<url>http://internal.company.proxy:7070/artifactory/apache-m2-incubating
<releases>
<enabled>true</enabled>
</releases>
</pluginRepository>

</pluginRepositories>

</profile>

</profiles>

Maven reporting plugins - useful for generated reports in the Maven-generated project site

We're currently setting up CruiseControl at work and are looking to
have more documentation on various aspects of each project. Adding
these settings to a Maven projects pom.xml would generate a lot of
useful information that would cover our needs.

<reporting>
<plugins>
<plugin>
<artifactId>maven-changes-plugin</artifactId>
</plugin>
<plugin>
<artifactId>maven-checkstyle-plugin</artifactId>
</plugin>

<!--

<plugin>

This plug-in provides functionality for accessing FindBugs
from Maven.

<artifactId>maven-findbugs-plugin</artifactId>
</plugin>

-->


<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<version>2.0</version>
</plugin>
<plugin>
<artifactId>maven-javadoc-plugin</artifactId>
</plugin>
<plugin>
<!--
The JXR plugin produces a cross-reference of the project's sources.
The generated reports make it easier for the user to
reference or find
specific lines of code. It is also handy when used with
the PMD plugin
for referencing errors found in the code.
for multi-module projects, see:

http://maven.apache.org/plugins/maven-jxr-plugin/examples/aggregate.html

-->
<artifactId>maven-jxr-plugin</artifactId>
</plugin>
<plugin>
<!--
The PMD plugin allows you to automatically run the PMD
code analysis tool on your
project's source code and generate a site report with its
results. It also supports
the separate Copy/Paste Detector tool (or CPD) distributed
with PMD.
-->
<artifactId>maven-pmd-plugin</artifactId>
<configuration>
<linkXref>true</linkXref>
<targetJdk>1.5</targetJdk>
</configuration>
</plugin>
<plugin>
<artifactId>maven-surefire-report-plugin</artifactId>
</plugin>
<plugin>
<!--
This plugin is used to inform your users of the changes
that have occured
between different releases of your project. The plugin can
extract these changes,
either from a changes.xml file or from the JIRA issue
management system,
and present them as a report.
-->
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-changes-plugin</artifactId>
<reportSets>
<reportSet>
<reports>
<report>changes-report</report>
</reports>
</reportSet>
</reportSets>
</plugin>
</plugins>
</reporting>

===================

Updated 6 March 2008: Commented out the Findbugs plugin entry because I can't get it to work yet. The settings above are actually for Maven1. To use the Maven2 plugin it should be like this:

<plugin>
<groupId>org.codehaus.mojo</groupId>
   <artifactId>findbugs-maven-plugin</artifactId>
   <version>1.1.1</version>
</plugin>

We are using Artifactory, but for some reason I get this Maven error:

[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Unable to build project for plugin 'org.codehaus.mojo:findbugs-maven-plugin': POM 'org.codehaus.mojo:findbugs-maven-plugin' not found in repository: Unable to download the artifact from any repository

org.codehaus.mojo:findbugs-maven-plugin:pom:1.1.1

from the specified remote repositories:
everything-else (http://192.168.1.1:7070/artifactory/releases),
snapshots (http://192.168.1.1:7070/artifactory/snapshots-only),
central (http://192.168.1.1:7070/artifactory/repo1)


However, when I got to repo1.maven.org (which is in my proxy configs), the Findbugs plugin is there at:

http://repo1.maven.org/maven2/org/codehaus/mojo/findbugs-maven-plugin/

So why is Maven (or Artifactory) unable to retrieve this plugin?

Again, what is going on here?

I guess I should test this first by removing Artifactory from the picture, removing the proxy settings from my settings.xml. If it fails, then it's a Maven issue. If it works, maybe it's Artifactory.

========================

Update:

Removed the Artifactory settings and Maven was able to download the plugin correctly. Maybe I should expire some caches and see if it is able to get the plugin?

Maven updates its plugin metadata then says it can't find the plugin - WTF?

Trying to generate the IntelliJ project files for a Maven 2 project.
Then I got an error:

mvn idea:idea
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'idea'.
[INFO] artifact org.apache.maven.plugins:maven-idea-plugin: checking
for updates from central
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).

Project ID: org.apache.maven.plugins:maven-idea-plugin

Reason: Error getting POM for
'org.apache.maven.plugins:maven-idea-plugin' from the repository:
Failed to resolve artifact, possibly due to a repository list that is
not appropriately equipped for this artifact's metadata.
org.apache.maven.plugins:maven-idea-plugin:pom:2.2-SNAPSHOT

from the specified remote repositories:
central (http://repo1.maven.org/maven2)

Now I look in my Maven repository, in the maven-idea-plugin directory, in

\.m2\repository\org\apache\maven\plugins\maven-idea-plugin

and I find the maven-metadata-central.xml which has this:

<?xml version="1.0"?><metadata>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-idea-plugin</artifactId>
<versioning>
<latest>2.2-SNAPSHOT</latest>
<release>2.1</release>
<versions>
<version>2.0-beta-1</version>
<version>2.0</version>
<version>2.1</version>
<version>2.0-beta-2-SNAPSHOT</version>
<version>2.0-SNAPSHOT</version>
<version>2.1-SNAPSHOT</version>
<version>2.2-SNAPSHOT</version>
</versions>
<lastUpdated>20070716221242</lastUpdated>
</versioning>
</metadata>

But when I look in the location:

http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-idea-plugin/

And get the maven-metadata.xml, it has:

<metadata>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-idea-plugin</artifactId>

<versioning>
<latest>2.1</latest>
<release>2.1</release>

<versions>
<version>2.0-beta-1</version>
<version>2.0</version>
<version>2.1</version>
</versions>

<lastUpdated>20070604220104</lastUpdated>

</versioning>

</metadata>

The only possible reason I can think of for this happening is that
Maven is getting the metadata from somewhere else. We are using
Artifactory and one of the repositories we have set up is an entry
pointing to http://people.apache.org/repo/m2-incubating-repository.
The artifactory.config.xml contains this:

<remoteRepository>
<key>apache-m2-incubating</key>
<handleReleases>true</handleReleases>
<handleSnapshots>true</handleSnapshots>
<excludesPattern>org/artifactory/**,org/jfrog/**,au/com/company/**</excludesPattern>
<url>http://people.apache.org/repo/m2-incubating-repository
<proxyRef>work-proxy</proxyRef>
</remoteRepository>

Now in this repository, there is a directory for maven-idea plugin, at

http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-idea-plugin/

and there is a file
http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-idea-plugin/maven-metadata.xml
that contains:

−
<metadata>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-idea-plugin</artifactId>
<version>2.0-beta-2-SNAPSHOT</version>
<versioning>
<latest>2.2-SNAPSHOT</latest>
<versions>
<version>2.0-beta-2-SNAPSHOT</version>
<version>2.0-SNAPSHOT</version>
<version>2.1-SNAPSHOT</version>
<version>2.2-SNAPSHOT</version>
</versions>
<lastUpdated>20070716221242</lastUpdated>
</versioning>
</metadata>

Now the strange thing is that this info is not exactly the same as
what's in my local repository. So it looks like the
maven-metadata-central.xml I have for maven-idea-plugin did *not* come
from this location. So where did it come from? I should probably add
to the exclusion list for the above repository so it doesn't try and
get maven plugins from there. But from the error message I got, it
looks like it only goes to the central repository at repo1.maven.org
for plugin updates. If that's the case, why does it seem to go
somewhere else for it's plugin updates?

What the hell is Maven actually doing?

Maven woes # 2923928923829: Maven metadata not reflecting what's on maven repository

(File under "Maven!!! GRRRRRR!")
Alternate longer title: What the hell is wrong with Maven and why do
they push out these SNAPSHOT plugins with releases to other SNAPSHOT
jars that don't even exist? As a matter of principle, should you
really be forcing non-release, snapshot software upon your users?
Here's what I was getting:
Error: Reason: Error getting POM for
'org.apache.maven.plugins:maven-archetype-plugin'
Unable to run Maven archetype because it is trying to download a
plugin that it can't get from the central Maven repository.
Turns out it's because of an inconsistency between the settings it has
in the location
\[username]\.m2\repository\org\apache\maven\plugins\maven-archetype-plugin\maven-metadata-central.xml
and what is actually on
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-archetype-plugin/
C:\dev>mvn archetype:create -DgroupId=au.com.company.myapp -DartifactId=my-app
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'archetype'.
[INFO] org.apache.maven.plugins: checking for updates from central
[INFO] artifact org.apache.maven.plugins:maven-archetype-plugin:
checking for updates from central
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).

Project ID: org.apache.maven.plugins:maven-archetype-plugin

Reason: Error getting POM for
'org.apache.maven.plugins:maven-archetype-plugin' from the repository:
Failed to resolve
artifact, possibly due to a repository list that is not appropriately
equipped for this artifact's metadata.
org.apache.maven.plugins:maven-archetype-plugin:pom:2.0-SNAPSHOT

from the specified remote repositories:
central (http://repo1.maven.org/maven2)
for project org.apache.maven.plugins:maven-archetype-plugin
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: < 1 second
[INFO] Finished at: Wed Feb 20 17:35:46 EST 2008
[INFO] Final Memory: 1M/254M
[INFO] ------------------------------------------------------------------------

Solution:
1. Go into
\[user]\.m2\repository\org\apache\maven\plugins\maven-archetype-plugin\maven-metadata-central.xml
rename this file or delete it.
2. Get the file
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-archetype-plugin/maven-metadata.xml
Download it to .m2\repository\org\apache\maven\plugins\maven-archetype-plugin\
and save it as maven-metadata-central.xml
3. Rerun the above process
mvn archetype:create -DgroupId=au.com.mydomain.myapp -DartifactId=my-app
now maven metadata is pointing to files that actually exist on the repository.
But the big questions here are:
Why is there a discrepancy at all? What other repositories could the
maven-metadata-central.xml be talking about if not the main
http://repo1.maven.org? Where did the maven-metadata-central.xml come
from anyway?
As a matter of design, why do I end up receiving - without my asking
for it - bleeding edge snapshot plugins? Shouldn't the policy be to
only use release versions?
Okay, maybe this argument is not really valid in this instance because
we are talking about the archetype-plugin. From the looks of what's on
the repository, it went out as 1.0-alpha-3 then to 1.0-alpha-5, then
1.0-alpha-7 - and now it's at 2.0-alpha-1. Good god, is this thing
*ever* going to get to an actual release number, one that doesn't have
greek letters after the .0?

Update on 6 Oct 2011:
NOTE: As commenters below have pointed out, the mixup normally occurs when you are - probably unknowingly - getting artifacts from both release and snapshot repositories.
The thing to remember is to make a distinction between release and snapshot repositories. The fact that you are pointing to a public repository is not enough. A repository obviously has to be public so that other people can access it. The question is: what types of artifacts are the repository providing? They may actually have both types.