[support-tony]

brgiles,

Thanks for the information so far; I can update the bug report a little. It’s a shame that the test project no longer exhibits the problem. If you can get another project up at that SVN URL, which does exhibit the problem, that would help.

One thing I noticed from the visual is that the .settings folder is not shared. Is there a reason for that? This led me to look at what might be in the .settings folder, since it isn’t always there. One of the settings it holds is for whether to resolve dependencies from workspace projects.I’m not sure if this could cause the problem so I turned off that setting in my own test and the Maven Dependencies library disappeared from the Package Explorer. This appears to replicate your problem so could you check that this option is turned on, in any project that is showing the issue? The preference can be reached by right clicking on the project and selecting Properties, then going to MyEclipse->Maven4MyEclipse.

If the above is not the problem, please try deleting the .settings folder (it can always be restored from trash later), if there is one, just to see if there are any settings that might be affecting this.

[brgiles]

I’ll try deleting the directory. I didn’t check it in because it’s been the policy at my recent shops because it’s tied a little too closely to the developer’s particular setup and would cause problems when it’s updated by other people. This is currently a one-person side project so it’s more habit than a specific concern at the moment.

[support-tony]

Yeah, it’s easy to get into a habit and stick with it.

I’m glad you’re back working on this; I was getting worried after your reference to wildfires!

I’ll wait for your word on deleting the .settings folder.

[brgiles]

I deleted the .settings directories but they weren’t recreated, at least after working with the code briefly (about an hour). Still no Maven Dependencies.

I’ve since put in a lot more time but forgot to check whether the directories exist yet – I’ll do that this evening. Using a local user library has let me get back to coding although it’s still a pain to test.

[support-tony]

brgiles,

I’m sorry this is taking so long to sort out but, without a way to consistently replicate the problem, it’s very difficult to track down the cause. I was keeping my fingers crossed that removing the .settings folder would lead to a resolution as changing that maven setting was the only way I could get the Maven Dependencies library to disappear.

Can you see any pattern emerging, at all, about which projects exhibit the problem? If you can get that test project you shared to reliably show the problem, then that might help.

[brgiles]

Good news, sort of. I created a virtual box image, did a clean install of Ubuntu 12.04, MyEclipse 10.5, and imported the project. The problem still occurs and I can set you something that you can work on locally.

The bad news is that the .ova file (the exported virtualbox image) is 3.8 GB. I’ll need to burn it to a DVD or even a memory stick and mail it to you.

[support-tony]

Hmm,

That’s awkward. We’re a distributed company and the DVD may need to go to multiple people who are looking at this, all in different countries.

However, as you have replicated the problem on a clean Ubuntu 12.04 image, if you can get that project to us somehow, then I could certainly try a clean image and MyEclipse install myself. I would then be replicating your system exactly and should be able to replicate the problem.

Did you import from the file system or from SVN? And did you import as an existing eclipse project or as a bare maven project?

By the way, the other problem you mentioned, with the message, “Path must include project and resource name: /” has been tracked down to an existing m2e (and eclipse project) bug. The bug is here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=361824 and concerns a target directory outside of the eclipse workspace. Could you check that bug report and confirm if your scenario is the same?

[support-tony]

brgiles,

Following the information I gave you in my last post, I tried the test project that you put up, but after altering the pom in subtest1 to direct the output to a folder outside the workspace. During the import of the project tree, I received an error:

Errors running builder 'Maven Project Builder' on project 'maven-test'.
Path must include project and resource name: /
Errors running builder 'Maven Project Builder' on project 'subtest1'.
Path must include project and resource name: /

The above error also occurs when I try to update the project configuration.

In addition, the subtest1 project has no Maven Dependencies library. So, we’ve managed to replicate both problems by specifying a target directory that is not in the workspace. Could you confirm whether this is the same scenario for your projects that exhibit the problem? If so, I’m afraid we’ll have to wait for the m2e bug to be fixed, or you can alter your pom to point the output folder(s) to somewhere within the project, if possible.

[brgiles]

I had seen that bug earlier and as a test had 1) set the output directories to “target/classes” and “target/test-classes” and 2) commented out those entries entirely and still had the same problem despite doing a ‘refresh’ followed by a project > clean to force a rebuild of the project.

Could something be cached that would cause the problem to remain even after changing the output directory back? I’ll try changing the output directories, committing it, nuking the project and checking it out again.

BTW I know that the external output directory worked in the past – as an experiment I put my workspace in a Dropbox folder and quickly discovered that builds would overwhelm it. That problem when away when I changed the output directory so it was outside of Dropbox. It’s too bad m2e has regressed – it’s also a clean way to manage the size of what you need to back up.

[support-tony]

brgiles,

I don’t think anything is cached. I just tried it. After having the target directories set to external folders (which had the issue you see), I just altered the target in the pom and saved it. Immediately, the error went away and the Maven Dependencies library appeared.

If you still get the problem after nuking the project and checking it out, could you attach (or attach to a private message) the pom of a project having this issue, so that we might have a chance at replicating the problem?

[brgiles]

I didn’t see a change when I saved the modified pom.xml file and refreshed the project but the problem finally away when committed the changed pom.xml file, I nuked the project and reimported it. I don’t know why there’s a difference in behavior between our sites but there is finally an explanation (existing known bug) and solution. Yay!

(The other bug description should probably be updated to report that some people have to nuke and re-import projects for the fix to work – I didn’t see a change so I assumed that that bug had been fixed in one of the updates.)

BTW I tried checking out the project to locations both within the workspace and in an external directory and both worked. I remember one of the earlier bugs mentioned problems if the project is external to the workspace – not just the output directories outside of the project – but I couldn’t reproduce that problem.

[support-tony]

brgiles,

Thanks for getting back to us and I’m glad we managed to find a workaround resolution to the problem. I’ve updated our bug but I’m not sure the eclipse bug requires additional info. However, you can always add a comment yourself, perhaps as a way to persuade the developers to actually fix it, though I can kind of see why they would be reluctant to do so, given that eclipse would then be building to an external location. However, with Linux, you can create a symbolic link for target, within the project but pointing at an external location. This seemed to work fine for me.

[Author]

Posts