Hi Stephen, Thx a lot for this feedback. I don't remember when and why we did these changes but I understand your problem. It seems that the autodiscovery of projects dependencies in the workspace is activated by default. I think that this feature should be deativated by default (First issue to open). The problem about projects naming is that maven identifies a project from groupId/artifactId/version. In Eclipse a link betwwen project is done using project's name which is by default the artifactId. Having groupID/artifactId and version in eclipse project's name is the better solution to not have problem of identification but after that projects are unreadable (except if you are working on a 54" display). I don't know what to do to have something logical to identify a maven project in eclipse. I didn't have a look to see how m2eclise and Q4E are doing to mange these case (several branches of a project in the same workspace)
On Mon, Apr 13, 2009 at 7:09 PM, Stephen Duncan Jr <stephen.dun...@gmail.com > wrote: > 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 > -- Arnaud
