Amongst several other surprising changes in the 2.6 release of the maven-eclipse-plugin, I'd like to explain on one change caused some confusion for myself and other members of my development team. I'm not sure it's really a bug, or exactly what feature enhancement to file, so I'm hoping this thread can help determine a better future outcome.
Background: We have many different components as individual maven projects, no multi-project/reactor projects, and Hudson continuously building and deploying SNAPSHOTs to Nexus. The typical workflow for a developer would be to check out any particular component they needed to work on, and they could run 'mvn eclipse:eclipse' to get the classpath right, and to download the latest versions of any dependent components (settings.xml defined the repository with a updatePolicy of always). If they wanted to make changes to a dependent component locally, they'd make the changes, run mvn install, and then refresh the project to get those changes. This all worked without any extra configuration of the eclipse plugin. Also, the name of the project in eclipse didn't necessarily match the artifactId in anyway; typically it matched the folder in Subversion (which is sometimes, though rarely, different from the artifactId), or the the name of the branch in Subversion (artifactId-version, where version might be a SNAPSHOT, or be something like 1.2.x). With the eclipse plugin 2.6, it seems new work has been done to try to identify other projects in the eclipse workspace, and use those as project dependencies, instead of jar dependencies in the local repository. To get the workflow described above, I've gone ahead and configured (in our corporate parent pom) the eclipse plugin to not do project references at all. However, I didn't have to specify that before (I think it only used to affect reactor-builds), and therefore our team did get confused by the new behavior. When all SNAPSHOT dependencies were being downloaded from the repository, the version was the timestamp version of the SNAPSHOT, and never matched a project in the workspace, and so it behaved as before, so no problem. However, once somebody installed a dependency locally, the version was just -SNAPSHOT, so the eclipse plugin believed it found a match in the workspace. However, the name it tried to use for the project reference was the artifactId, not the actual name of the project in eclipse, and therefore the project showed up as broken in eclipse, due to the unsatisfied dependency. I think it would be better if the default went back to only doing project references for reactor builds. I also don't know if there's some better way to figure out the right project name to use for the reference. Even if our dependency had been named to match the project reference, somebody working on the branch may have gotten the WRONG project reference (the trunk would have the artifactId, but the wrong version, the branch project name would be the right version, but not match the expected name). -- Stephen Duncan Jr www.stephenduncanjr.com
