[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_72391 ] Scott Cytacki commented on MNGECLIPSE-59: -----------------------------------------
The embedder has been updated already to include the changes: MNG-1937 The embedder checked into the m2eclipse svn includes these changes. The latest version of my patch project-artifacts-2006062900.patch, applies to Trunk correctly. I had to set the fuzz factor to 3. And I had to manually select all the patch items that have red exclaimation points. More details on those red marks are here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=143354 All the patches really only take 2 approaches: those that add an eclipse artifact resolver to the embedder and the one that does not. * With the eclipse artifact resolver, the embedder uses the eclipse maven projects when it is looking for artifacts. In this case the eclipse maven projects do not be to installed into a maven repository, before they can references by other poms. This is useful when checking out a collection of interdependent eclipse maven projects that haven't been installed or deployed. See below for a use case. * Without the eclipse artifact resolver, when maven tries to find a pom or dependency it will not use the eclipse maven projects. So the artifacts must be available through the normal maven artifact resolution process: installed/deployed into a maven repository. This causes strange behavior, m2eclipse will use the pom from the maven repository, but will use the classes from eclipse project. So for example if A depends on B and B depends on C. A and B are eclipse maven projects. Then the pom of B is changed to add D as a dependency so B no depends on C and D. B is not installed or deployed. The dependencies of A will not include D. This is because m2eclipse is asking the embedder for the dependencies of A, and the embedder is using the pom for B from the maven repository not the pom from the eclipse project. So the 4 patchers are: Mark - ArtifactResolver-try3.patch Kenney - MNGECLIPSE-59 Drew - mngeclipse-59-drew-hack.txt Scott (me) - project-artifacts*.patch * Drew's patch does not add the eclipse artifact resolver to the embedder. * Mark's patch did add the eclipse artifact resolver to the embedder, but at the time he wrote the patch the embedder did not allow adding new artifact resolvers. So Mark also had to supply a patch to the embedder to make his patch work. Since then the embedder has added this functionality in a slighty different way. * Kenney made Mark's patch compile with the Trunk and with the embedder in the Trunk. But it accidentally removed the call that added the eclipse artifact resolver. * My patch is an update of Kenney's patch making it work with the Trunk and added back in the eclipse artifact resolver. It was then modified to be more modular so it would touch less of the m2eclipse code. So in conlusion, you need to decide if you want to use the eclipse artifact resolver. I believe using it will give the most consistant user experience. If you do use the eclipse artifact resolver, then my patch is the most up-to-date. > Allow artifact resolution from workspace projects > ------------------------------------------------- > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Issue Type: New Feature > Components: Dependency Resolver > Affects Versions: 0.0.4 > Reporter: Leonardo Quijano Vincenzi > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt, project-artifacts-2006062701.patch, > project-artifacts-2006062900.patch, project-artifacts.patch > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
