Allow artifact resolution from workspace projects

We're really stuck on this. So far the only solution we have is to have two pom.xml, a pom.xml for the maven eclipse plugin and a pom-server.xml. The difference between the two is the pom.xml doesn't contain dependencies for the projects that are in the eclipse workspace.

Is there a better solution?

Is there any plan on including the functionality there was in the maven 1 plugin for setting eclipse project property in the pom file in the maven2 release? What I am looking for is the possibility for plugin to override the pom file dependency with eclipse workspace dependency that should be used when available. I It is a really awkard to manage the dependencies in two places.

Something like in the maven 1 release to set the following property in pom file:
<properties>
<eclipse.dependency>true</eclipse.dependency>
</properties>

The plan is to always use code from Workspace if version matches. It won't be necessary to have anything special in pom. Though I can't give you any estimate on this, because most of the work is actually in the Maven ebedder component.

I took the liberty to resolve the problem of workspace artifact resolution. The attached patch file has it all.

The way it works is that when an artifact is resolved, the resolution is channeled through an Eclipse-based artifact resolver, which will first look for a Maven2-enabled project in the workspace, with a pom file that declares the exact version ID which is requested. If that happens to be the case, instead of adding a JAR dependency to the local repository, instead a project dependency is added to the Maven2 ClassPath container.

I had to slightly change the code in MavenEmbedder to allow this. The patch is uploaded to the MNG-1937 issue, mentioned in the dependencies. I did not explicitly allow substitution of the artifact resolver. Instead, I allowed changing the Plexus Embedder context before looking up components. This happens to make the necessary subsitution of the artifact resolver trivial. It's a oneliner in EclipseMavenEmbedder now, referring to the EclipseArtifactResolver.

patch to allow Eclipse workspace artifact resolution

In order to use the patch, you need to use a newer version of the embedder jar file. Uploaded as well. As soon as the embedder patch is in the current codebase, the SNAPSHOT nature of the jar can go away. See MNG-1937 for the resolution that needs to go in Maven Embedder proper.

I tried applying the attached patch (EclipseArtifactResolver.patch), but it seems garbled starting with line 862. Looks like a comparison with a unicode encoded file wend wrong... Is there a correct version available?

Jochen,

I apologize for the issue with the patch file. I'll try and fix the patch this weekend or the Monday after and upload a better version. I'm fairly new to SVN patches and I'm pretty sure the error is human (that is, on my side ).

Somehow the SVN was mixed up about the repository version of Maven2Plugin. Here's the correct version

All right - here you go. A corrected patch file. This time I checked the contents and they look benign. So have a go and let me know whether you like it!

The patch appears to be missing the EclipseMavenEmbedder referenced in one file. In addition if you have a project that is closed in your workspace, ALL the artifact resolution will fail. This is because Maven2Plugin.getWorkspaceNature(...) does not test if a project is open before trying to get its nature. this can be fixed by adding a project.isOpen() call and automatically continueing the for loop if its false.

All right - final attempt. This time I asked a colleague to verify the patch before uploading. He confirmed the patch works both on HEAD (2.1) as well as on the 2.0.x branch

Will this patch be included in the future release? Could you estimate when this would happen? It's a rather serious enhancement from my point of view...
I tried to apply this patch against the SVN trunk, it didn't work as expected. Was anyone successfull with it?

Hi Dimitry,

Milos Kleint is working to get the patch applied to the trunk (in MNG-1937, in an effort to solve MNG-1665). So you may want to watch his progress.

The patch did work against the trunk a couple of weeks ago. Since then, I changed jobs and I still have to setup my dev enviroment. So bear with me for a while

Hi Mark,
Thanks for the response. I think the approach you're taking here is quite exciting and looking forward having this functionality implemented.

Hi Mark,

I managed to recompile and run the plugin. It works well. But there were couple issues I ran into:

1) It still crashes inside of Maven2Plugin.getWorkspaceNature() for "project.getNature" when project is closed. I added check for project's closed/open status - it was fine.
2) Just to be aware, you had "libraryEntries.add(JavaCore.newProjectEntry(...)" inside of the if with "("jar".equals(a.getType()) || "zip".equals( a.getType() )" which was since changed to "artifactLocation.endsWith("jar") || artifactLocation.endsWith("zip")". For the obvious reasons your code for adding project to the classpath is never called now (since location is "pom.xml" in that case). I had to move it outside of plugin, it was fine as well.

Hi Mark,

There's another issue with this implementation. It's in the area of PDE development and probably is only particular to PDE environment, but this is important b/c there's big number of Eclipse plugin developers and that number is growing.

The issue is that PDE has its own way of simplifying dependencies and this way is essential to the PDE's work. Thus, dependencies information might get duplicated (or some of it) in the pom.xml and PDE-s manifest. The same project would appear in both "Plugin Dependencies" and "Maven2 Dependencies" classpath containers, which triggers build error in Eclipse (duplicated classpath entry).

It seems like the only way to resolve this problem would be to avoid including artifacts in the "Maven2 Dependencies" container if they present in other containers. Although I don't know how possible this is, I don't know if the order in which classpath containers are expanded is known and if there's the necessary information to do this.

Thoughts?

Hi Dimitry,

Unfortunately, I have not walked through the scenario you described. The colleague I worked with is on holiday for a couple of weeks, so I'd need to work on this myself for a while. However, my Eclipse install is still gathering dust. Any thoughts from other members of the community would be appreciated. I'll send this link to some other folks I know to see if they know something...

Hi Mark,

Another issue that should also be considered is WebTools support. It, pretty much, has the same issue. I.e. WebTools manages dependencies on its own (on the "J2EE Module Dependencies") and sycnrhonizes them as the project classpath dependencies. If Maven2 was enabled for the project this would yield "duplicate classpath entry" error.

Guys, before you go too far here. I'd like to suggest to investigate options to somehow make WTP classpath containers to pickup dependencies from Maven container.

I don't really like the idea of selectively removing classes from container or maintain synchronization with WTP config files.

It would make sense to open separate issue for this stuff.

I agree. These are two different issues:

1) WebTools is actually not a classpath container, they use the regular project dependency. The J2EE module dependency is stored in the ".component" file. Modules in this file are synchronized with the project's classpath when they're added. This synchronization operation is what actually fails b/c classpath contains the dependent project already (provided by Maven2 classpath container). This could be probably resolved by having Maven2 plugin to automatically extend ".component" content for the non "provided" dependencies (altough I don't know if there's API or extension points there to do that).

2) PDE plugin dependency. They are provided by the "Plugin Dependencies" classpath container. So they would be in conflict with Maven2 classpath container. I understand that PDE container is instantiated based on the "Require-Bundle" property from the plugin's MANIFEST.MF. This manifest is essential for PDE system to work properly (actually for OSGI). I don't think there's an obvious way to avoid a conflict b/w these two containers (PDE and Maven2), b/c it's not likely one can disable another container.

If there're no objections, I'll open two new issues in addition to this one: one for webtools support and one for pde support.

Thanks Dmitry. Please attach some example projects to reproduce those issue.

My company is evaluating using m2eclipse. Our culture is to check out multiple projects at once while developing, but reference others from the maven repository. We also have a team that is doing PDE development. So this particular issue is basically a deal breaker for us.

+1 from us...

I believe the patch can be applied already. The blocking issues have been resolved, although, I don't know if they have been released already.

There's one outstanding issue here though. It doesn't block the progress on this item, but it'll be very nice to have.

Currently m2eclipse resolves artifacts in the repository via local file system paths. I.e. inside of the "Maven2 Dependencies" there're entries such as "C:/Documents and Settings/USER/.m2/repository/group/artifact/../x.jar". This prevents other plugins from referring to such entries in the sharable manner. For instance, we're using Sysdeo, which can be setup to start Tomcat's application with the subset of jar files or projects resolved via Maven2. But it's not possible to share this information b/c every user has different home. The solution sould be to have m2eclipse define classpath variable (e.g. M2_REPO or such) and resolve all artifacts via such variable. In the example above it'd be "M2_REPO/group/artifact/../x.jar". Such entries can be shared w/o problems.

FYI: Otherwise Sysdeo (http://www.sysdeo.com/eclipse/tomcatplugin) is quite easy to setup to work with Maven2Eclipse plugin. However the current release version has some issues for this to work properly in case of project dependencies (jar files should be fine). I submitted a patch to the Sysdeo team that should fix the issue.

Unfortunetely, it looks like Eclipse's classpath containers cannot contain variable entries. Per IClasspathContainer JavaDoc:

"... a classpath container can neither reference further classpath containers or classpath variables."

I don't know what's the reasoning behind this, but, I guess, we'll have to do w/o this functionality.

Dmitry, belive me, I've gone trough this already. This if why it is how it is now.

I see
I made a note in Eclipse's bug system: https://bugs.eclipse.org/bugs/show_bug.cgi?id=142135
They're planning to remove this limitation in 3.3, but for you this, of course, doesn't matter.

Eugene, is something still holding the patch suggested by Mark? I had it running in our environment for some time now, it works just fine. If you need, I can resend you the same patch agains current trunk...

Primary constraint is my time. So, patch against trunk will help and would allow to cleanup outdated attachments... Thanks.

Applied the patch to latest from trunk, manually fixed the errors because of the
changes in the repo since the patch was originally filed.

Updated to latest maven-embedder-2.1-SNAPSHOT from trunk (this version doesn't
match the one attached). You'll have to manually build from maven trunk
and replace the lib/maven-embedder-2.0.4-dep.jar with maven-embedder-2.1-SNAPSHOT-dep.jar. The config files (property, manifest, plugin.xml) are all updated and need no change.

Fixed some other errors due to this patch and the changes in the embedder - updated api calls etc.

Replaced the xpp3reader call to get models from m2 enabled projects
to use the embedder to build a MavenProject and use that model,
so it's inherited and interpolated properly (for instance in my testcases the groupId
was null because it's inherited from the parent).

Tested and works, although 'update source paths' doesn't quite work. Not sure if I broke
it with this fix.

I'm not comfortable with this coding style, and even reformatting using the configured
coding styles gave differences to the versions in svn, so I've not formatted the code - it might be ugly at places.

I hope this patch is useful.

Hi Kenney,

While ago I tried the patch and ran into issues described in one of the comments above above (see "It still crashes inside of Maven2Plugin"). Are they addressed as well? If not I can provide a separate patch for them once your patched is applied.

I've hacked together a solution that seems to work for now and only touches the Maven2Plugin class. I've generated the attached patch against version 111 of Maven2Plugin and attached it as mngeclipse-59-drew-hack.txt

The drawback of this solution is that it builds a list of projects in the local workspace that could potentially be used to resolve dependencies once, the first time resolveClasspathEntries is called. Ideally, I'd somehow hook into workspace change events and rebuild the list as necessary, but I really don't know the Eclipse API that well.

Furthermore, it only looks at the group id and an artifact id – version is ignored completely for now.

As I said, this is a hack – it seems to solve the issue for me – maybe this will be useful to someone else.

Drew, what is this fix for exactly?

Dimitry,

It's an attempt to get the eclipse plugin to resolve artifact dependencies by looking at workspace projects instead of looking for artifacts (jars) in the local repository.

It does this by cataloging the projects in the local workspace that are maven projects. In the resolveClasspathEntries() method, it checks these for group and artifact id's that match the artifact that is being searched for. If found, it adds a project reference to the Maven2 Dependencies library instead of a jar reference.

I believe this is what Mark J. Sinke's original patch does and it does it in a rather elegant way. I had it running on our workstation for quite a while now and works well. As far as I understand Kenney Westerhof (see above) adjusted the patch for the current trunk.
Does your patch do the same?

There's no need to patch or rebuild the embedder with the approach I contributed – which may be useful for people without the time or patience to do so until Mary/Kenney's patch gets rolled into a release.

The patch I contributed works although I won't comment on how elegant it may or may not be. Perhaps someone else will find it useful.

In my opinion main goal of this functionality is to have only one version of .classpath and pom for each project. It should be versioned with projects in CVS or SVN. If somebody wants to work on single projects only, he checks out only this project. Correct dependencies are downloaded from m2 repository. If sombody decide to work on other projects connected with dependencies, the only thing he has to do is to check out correct versions of these projects. No changes in pom nor in .classpath are needed. There will be no reqiured projects declarations in "java build path".
I thing it will be a huge improvement for people working on complicated project sets, to allow them to work only on projects that they are interested in without forcing them to change anything in build path or to check out everything.

Kenney, can you please merge your code with trunk changes and recreate patch afte that? I can't apply this one.

I went though the patch and updated it for the trunk. I tried to remove as much uneeded stuff as possible. It works for me. Because of subclipses limited patch creation, this path has lots of extra directories. When you apply it you just need to adjust the "ignore leading path name segments".

The patch allows the eclipse compiler to use projects in the workspace instead of artifacts in the maven repo. However...

I'm not sure if the original patch was supposed to make maven goals (run from the external tools menu) work with project eclipse project based artifacts. It seems like it should, since it has a custom artifact resolver. But when I tested my updated patch, it doesn't seem to do that.

getWorkspaceNature(Artifact) method iterates over all projects every time it is called.
Isn't it a good idea to cache natures in map indexed with artifact key and reset this map only if needed?

static Map getWorkspaceNatures() throws CoreException {
IProject[] projects = ResourcesPlugin.getWorkspace().getRoot().getProjects();
Map natures=new Hashtable();
for (int i = 0; i < projects.length; ++i) {
IProject project = projects[i];
if (project.isOpen()) {
Maven2Nature nature = (Maven2Nature)project.getNature(NATURE_ID);
if (nature != null) { natures.put(nature.getArtifactKey(),nature); }
}
}
return natures;
}

I'm using lastest trunk sources for maven eclipse plugin (with embedder 2.1-SNAPSHOT inside)

I would like to use theses patches to try the enhancements, but the new embedder doesn't seem to read settings.xml. Is it a regression or something in the embedder has to be configured ?

in patched Maven2Plugin class:
Why method: getModel(IFile file)
uses:
getMavenEmbedder().readProjectWithDependencies( file.getLocation().toFile() ).getModel();
instead of quicker:
getMavenEmbedder().readModel(file.getLocation().toFile());
?

Caching artifact key in Maven2Nature instead of parsing model/project every time seems to be good idea too

Hi Eugene,

There seems to quite a bit of confusion around this issue now. I just wanted to see if if something can be done to clear things up. I don't know what's the state of applied patches right now, but I believe, Mark J. Sinke patch was very satisfactory. I've had it running on our workstations for a while now. If you need help applying that patch, I can adjust it to the current trunk. I believe, all other optimization requests can be easily applied afterwards. If you other patches were applied (i.e. Kenney Westerhof) please let me know, I'll try to test it over here.

Hi Dimitry and Eugene,

I'm sorry for any confusion that I caused, but I assumed that Kenney's patch was the most uptodate. Based on Kenney's comments Mark's patch would not apply to the trunk, so Kenney patch was just updating Mark's patch for the trunk.

It was my belief that the best way to help Eugene was to make sure that the patch would be easy to apply to the trunk.
Continuing with that approach I noticed that my last patch no longer applies cleanly to the trunk, so now I'm updating it.

After looking more closely at the two patches: Mark's and Kenney's. I realized they are not the same. Kenney did add the eclipse artfiact resolver to the plexus container. However, Mark's approach for adding it no longer works. The way that Milos implemented it was different than Mark's original approach. You can see that discussed here: http://jira.codehaus.org/browse/MNG-1937

I figured out how to add the eclipse artifact resolver to the container using the version of the embedder currently checked in to the org.maven.ide.eclipse project. I'm cleaning up a patch with that in it now, and I'll post it soon.

The patch is now attached. I had a bad typo in the previous comment. Kenney's patch did not add the eclipse artifact resolver to the container. This patch does do that.

This patch still could use some work:

• it should use the executeInEmbedder methods
• it should cache the artifact key in the mavennature,

I'm working on those now. I don't think it is worth caching the list of projects with maven natures.

Note if you are using 3.2 to apply the patch you need RC6 or later. Otherwise you won't be able to add the 3 new files in this patch. See this bug for details on that one: https://bugs.eclipse.org/bugs/show_bug.cgi?id=143354

Here is an updated patch that should be easier to maintain. It requires very minimal changes to existing code. Instead of adding methods and attributes to the Maven2Nature, I took the approach used by the PDE. So there is manager class: MavenModelManager that maintains a mapping from projects to maven information.

The previous patch did not handle poms that inherited their groupId. This one does. It also does not use the MavenEmbedder because it only needs to read the pom.xml file. This can be done with an instance of MavenXpp3Reader.

It does seem like maintaining a list of the artifacts that are provided by the eclipse worksapce would be worth doing. This would require listening to any changes in project open, closing, removal, and maven nature adding and removing.

The patch fixes a number of issues that I had reported in MNGECLIPSE-147, however it does not seem to find resources, only the actual classes.

System.out.println(XXX.class);
interface xxx.XXX

System.out.println(XXX.class.getResource("/META-INF/applicationContext.xml")); -
null

System.out.println(new ClassPathResource("/META-INF/applicationContext.xml", XXX.class).exists());
false

False alarm. Was actually to do with some of my eclipse source paths being out of date. Just something to watch out for when you switch to this patch.

Still working through classpath issues with resources, but have got past a couple so far.

Scott Cytacki
Can you repost your patch? all attachment seems lost from this server.
thanks
Andrew

I just checked the attachements and it seems they are back. I see that this issue has been marked unassigned.

Can someone who has commit access, describe what needs to be done to get this into checked in?
Do we need a few people to test it?
Is there something wrong with the code that is keeping it out?
Do I need to address the performace issue mentioned above:

• add a cache to maintain a list of maven eclipse projects instead of rebuilding it on each use of the classpath container.

It's been a long time for this one. Is anyone committing changes?

We've been using the patch provided by "Mark J. Sinke" for quite a long time now. It works very well for us, although the code would need to be cleaned a little (to provide for correct progress bar update, logging, etc). If a new patch will be applied to the repository, I can install it over here and run for some time to get it tested...

I just assumed that the reason that this hadn't been resolved was due to the Maven Embedder. Obviously there is a working patch, so what is stopping this patch from being applied and a new version to be released?

Folks, I see 4 different patches that presumably take 4 different approaces to resolve this issue. Unfortunately I haven't had enough time to try them all and choose which one is working best. If anyone can tell me what patches can be eliminated now it will be a big time saver for me.

It also seems that most of those patches (if not all) are outdated now and can't be applied without manual intervention. So, I'd like to ask their authors to resync with the latest code from the head and resubmit their patches.

If anyone can email me what exactly need to be fixed in Embedder I can try to push for it.

Thanks in advance and sorry for the trouble.

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.

I believe it should definetely be a version with the eclipse artifact resolution. Again, I can do the accepting testing pretty quickly over here as we've been using Mark's patch for several months now.

I applied the patch to a clean check out from Trunk last night, built and upgraded to the 0.0.10 plugin. It appears to work fine in terms of doing what it's meant to; however, I had dual entries in the classpath of many of my projects because I had previously put the project in the POM and added it as a project in the Eclipse classpath. Particularly in the case of a WTP project that made the whole workspace unstable - in fact the only way I was able to remove the duplicate entries from the WTP project was to close the workspace, go into the .settings folder via Windows Explorer and remove the WTP dependencies manually. Which makes me wonder if having a dual entry on the classpath results in some kind of infinite loop? I'm fairly sure that vanilla Eclipse lets you recover errors like that without needing to alter files in notepad.

Very minor point - if you have project A in the workspace specifying version 0.1 of project B in its POM and project B version 0.1 in the workspace, it is correctly resolved as a project. If you then change project B's POM to version 0.2, project A should immediately break (or resolve to the repository if you installed B0.1 at some point). In fact it carries on merrily resolving to Project B in the workspace until you make an edit to Project A's POM, at which point it resolves the reference to B0.1, realises it isn't in the workspace and acts appropriately.

It would be nice if the plugin did a resolve of all Maven2 projects in the workspace when any POM is updated, to avoid this issue. Not sure how expensive that might be, or whether you could do a targetted resolve of only references to the project whose POM had changed. I'll have a look at the code.

Dimitry, some testing would be great.

Robert,
Regarding the duplicate project dependencies. I would expect the JDT to handle this, I'd be curious how this is handled by the eclipse plugin classpath container.

On the second point, I agree, A should update as soon as B's pom is saved. Since m2eclipse is already listening to pom changes this should be straight forward. To optimize, each maven eclipse project can listen to all of its dependencies which are maven eclipse projects. We might need a new event for this, but hopefully there is an existing event we can use.

Performance is something that needs to be tested. There is a lot of room for improvement, but I didn't want to do it without reason.

Scott, thanks for update and great explanation. I applied patch, but it require some cleanup and refactoring before I can commit.

Apart from that, this patch does not handle projects that include multiple modules, but it probably should go into a separate issue.

Robert, please fill separate issues for things you found, such as refresh stuff and WTP issues (though I think Dmitri already created one for WTP).

BTW, it is also interesting to have an option to use this resolver when launching maven (including launcing linked to the build events). Will require additional investigation, since forked maven process don't have Eclipse stuff around.

Eugene, We've got a multimodule maven project. I've tried both approaches, i.e. seperate eclipse projects and a single one with lots of source paths.

Using a seperate eclipse project for each of the modules is a much better approach.

• it brings the eclipse the eclipse build paths very close to the maven build paths i.e. source, seperate output directories (although test resource scoping is not complete).
• it stops you creating dependencies that break in the maven build i.e. cyclic dependencies between modules.

However this approach only works with the patch applied. I would guess a lot of the requests for multi-module support in a single project would not be required if the patch is applied and released.

created MNGECLIPSE-179 to dicuss this option of using the resolver in forked maven builds.
created MNGECLIPSE-180 to track handling of multi-module projects by the eclipse artifact resolver.

created http://jira.codehaus.org/browse/MNGECLIPSE-181 to discuss updating projects that depend on the changed project on POM saving

Maven and WTP: MNGECLIPSE-107
Maven and PDE: MNGECLIPSE-106

I took last patch from Scott, refactored it to be more integrated with builder and committed changes to svn.

There are some issues with rebuilding dependent projects on pom changes or when project that contain dependency is closed or deleted. But I think it is usable.

Scott, I think that multimodule project should work after my changes, but it could use some more testing...

I just checked it out. The refactoring looks good, and thanks for updating the eclipse formater settings. But...

It only worked for a few seconds, and then all the eclipse project dependencies disappeared from the classpath container and were replaced with maven jar dependencies. I'll try to figure out what is going on.

I pushed some fixes. Namely: changed key in models Map to string (I wonder if it would fix your issue) and fixed issue when artifact version is defined in the parent pom.

However there is some weirdness. For instance, when I import maven-tools project from http://svn.apache.org/repos/asf/maven/components/trunk/maven-tools I see some broken dependencies and it looks like maven-core is not being resolved transitively. Not sure if it is anyhow related to the last refactorings or it is just broken snapsht dependencies...

I think I tracked down the source of my problems. The artifacts map in the MavenModelManager is not be initialized correctly. When eclipse is started this map is empty, and it is only populated when pom is opened and changed.

So at some point when the plugin is starting up it needs to search through the projects and build up that map. Or the map needs to be serialized, but it seems a lot safer to build the map at the beginning of each startup.

I also see that the model manager is using the embedder to read the poms. This makes sense, but it is tricky, because it is easy to create infinite recursions. If the artifact resolver causes the model manager to read a pom then the embedder will ask the artifact resolver to do some resolving which then asks the model manager to read a pom....

I'm not sure yet what the best way to prevent that. In my original patch I was avoiding the use of the emedder, but that meant the code had to reimpliment the logic for figuring out the version, goupId and artifactId from the raw pom.

Good catch. Maven2ClasspathContainerInitializer should invoke updateMavenModel(..) method when recreating maven conainer...

Using embedder to read the Model should be fine in this case because it does exactly what your code did and i don't really want to expose all the reader classes into plugin code. So, there won't be any recursion.

I created a sub-task to work on the patch for initializing the artifact map: MNGECLIPSE-182
I've posted a patch there that takes care of it for me.
Without this initialization there will be many broken dependencies especially if projects are only available in the ecipse workspace.

There are still problems on open/close or checkout/delete projects declared as dependencies in other project's pom.

Marek, please provide exact steps to reproduce. Thanks.

Step 0:
Turn on auto build

Step 1:
Import attached simple projects

Step 2:
Deploy library project (jar and pom) into maven2 repository

Setp 3:
Clean workspace to ensure situation on picture 1

Step 4:
Close library project (picture 2).
Repository jar should be used, but eclipse is still looking for project
"Project application is missing required Java project: 'library'"
Cleaning workspace has no effect.

Step 5:
Close eclipse, and reopen it
Situation is still like on picture 2

Step 6:
Clean workspace
This time it has effect, and jar from repository is used (picture 3).

Step 7:
Open library project
Project is available, but jar is still used. (picture 4)
First clean has no effect.
Second clean has effect and we are back in step 3

Similar problems occurs on deleting and e.g importing library project.
When auto build is on, no workspace cleaning nor closing eclipse should be needed.

I think this scenario is already in the works under MNGECLIPSE-182

Kenney, there is no work is needed for this issue.

This seems pretty much implemented by now, isn't it?

I am going to close this issue as Fixed. Let's track outstanding stuff in separate issues.