Malabar can't find local dependencies

[bdarnell]

I'm still getting up to speed on a new project and maven in general so I haven't been able to pare this down to a minimal reproduction, but on my (large, multi-pom.xml) project malabar can't seem to find classes defined in other sibling modules (although it can find all the third party dependencies).

From poking around in the groovy shell it looks like MavenProject.artifacts and MavenProject.dependencies are disjoint sets: "artifacts" contains all the third-party jars I'm importing and "dependencies" contains all the references to sibling modules. It looks like the target directory for each of these sibling modules needs to be added to the classpath (at least for this project; I don't know whether we're doing anything nonstandard).

[m0smith]

Thanks for reporting this. What you say makes sense. It will be good to setup a sample project that exhibits this behavior.

[bdarnell]

OK, I think I've got a minimal reproduction. Try to import class Bar from FooApp.java in https://www.dropbox.com/s/0ik6plgndqgvi38/malabar-report.tar.gz

[m0smith]

Thanks for providing this sample. Would you be willing to donate it to the project? I am going to gather different scenarios for unit testing purposes and this is a great first step.

This problem has been around for a while: https://github.com/m0smith/malabar-mode/issues/38 See there for a possible work around.

For example, if I am in malabar-report/foo and I execute from the command line mvn clean package I get this error:

[ERROR] Failed to execute goal on project foo: Could not resolve dependencies for project com.example:foo:jar:HEAD-SNAPSHOT: 
Could not find artifact com.example:bar:jar:HEAD-SNAPSHOT -> [Help 1]

It is only in the context of the PARENT pom that the dependencies between foo and bar become apparent.

I have been considering the concept of a "workspace" which would be a collection of projects that, while not directly related, are related either indirectly through being modules in a parent or simply logically in mind of the developer.

This will be a good start into that space.

[bdarnell]

Yes, of course I'd be willing to donate this test case to the project.

I hadn't noticed that the individual pom files weren't enough to compile on their own (or even discover that there is a root) - the workflow for this project is to always run maven commands from the root, and to open only the root pom file in intellij. I think in this case it makes sense to just have a global (or dir-local?) variable pointing to the pom file to be used (at least as a last resort when the heuristics fail)

[m0smith]

Thanks. I think this is a common situation with maven. I am definitely dedicating some hammock time to it. http://www.youtube.com/watch?v=f84n5oFoZBc

My current thought is to prefer the current pom but if that fails to resolve a dependency, look for the parent pom. I also think the developer needs to know when that happens as it seems to be bad form to have the editor resolve dependencies when maven would fail.

[m0smith]

After thinking about this issue, the right thing to do appears to be to always check the parent pom and if the pom we found is a module, to use the parent. As a developer I think I would always want to treat the modules of a project as part of the greater project.