External classes aren't resolved correctly and therefore show up as errors

[florianb]

This is because at the moment there's no specific class-path specified and javac falls back searching the working directory and the user-specified classpath.

Therefore a search-strategy must be found to correctly resolve classpaths for different project types (like maven, gradle, eclipse and so on). A unresolved question is if the linter should enable the compiler to detect if the setting-files are correct or not.

[aengelke]

What about running javac in the src directory, without moving the file to the temp folder? Eclipse doesn't check for errors, if the file isn't saved. It should be possible to parse the src folder from the package name.

[florianb]

Hi @aengelke, thanks for taking part in the discussion and your suggestion. Unfortunately is the linter-javac-package part of the atom-linter-package which - by convention - handles the whole parsing process outside the current project folder.

But i get your point, you're suggesting letting javac parse the source-files from within the project-folder to let it be able to recognize the class-files of your project.

This will work as long as you're not using any sophisticated project-layout and your external classes reside within the corresponding CLASSPATH-folder. So that solution will fail if you're using a build-management tool like Maven or Gradle. Since I haven't figured out a proper way to recognize the state of the project and assure that the error-indication of javac for classes is reliable, I decided to leave it as an error. Probably not the best solution. What do you think?

[admwx7]

My Java skills are a tad rusty, having to get back into it to write some API's for my current job even though it's out of scope for my role...but I'm running into this issue as well. Based on above, can you not rely on using the package declaration at the head of the file then bundle in class name, the same way import paths are generated? Upon javac, build a map of import namespaces to classes that can be used for linting throughout the file, probably not the most efficient method, but it would solve the problem. A easier to implement short-term fix would be to allow for configuring the root of the class search via the cson file in atom.

[florianb]

@admwx7 these are two good ideas, i'll try to implement that the next time i've some minutes to spend. 👍

[dmnd]

See also steelbrain/linter#282 which might be a less complex way to deal with imports.

[tgaurnier]

Does Atom provide a way for packages to get the root project directory? If so wouldn't it be easier to just recursively scan the project directory for .java files and add them all to the class path? Also maybe you can add support for some type of a .classpath file in the root of the project directory? I know that AtomLinter lints files from a temporary directory, but if you are passing all the 'class path' values as absolute paths it shouldn't make a difference where the linting is taking place. If there ends up being an issue with the file being linted also being in the classpath, just strip the existing file from the classpath during the linting process.

[nemzes]

Building on the "per project config" idea from @tgaurnier, a "project type" setting could allow for the classpath discovery mechanism. For Maven, for instance, it could use this: https://maven.apache.org/plugins/maven-dependency-plugin/build-classpath-mojo.html

[lunij]

This is an one year old issue. Is there someone still interested to implement this? Otherwise this package is totally useless without this implementation.

[viniciuspires]

I'm also affected by this. I still haven't messed around with Atom Linters API, but does it allow an easy way of per-project configuration? If it does would it be simple as classpath configuration to pass via -cp argument, or am I over-simplifying it?

If it's as simple as that I can try to get a weekend to work on that.

[lunij]

That's the question. I don't have much experience with the Atom API yet, otherwise I'd try out exactly @viniciuspires's approach.

[brampersandon]

I'm somewhat familiar with the Atom API, I'll give the -cp method a go this afternoon. :)

[tgaurnier]

@lunij, the package isn't "totally" useless, there is a workaround that we can use in the meantime. Open a terminal in the root directory of your project, and launch Atom as such:
CLASSPATH="classpath_1:classpath_2:etc." atom .

Also note that each classpath should be an absolute path.

This way Atom and all of it's sub-processes will share the class paths, and all should work as expected. Don't get me wrong, we shouldn't have to resort to this, but it's at least a usable workaround. What I do is just create an 'atom' script at the root of my project with the command in it, then I just run atom from a terminal in my project root directory.

[steelbrain]

Please note that this bug will be fixed as soon as this linter upgrades to the new Plus API.

[nemzes]

@tgaurnier that's quite neat. Then, for Maven projects you can do this:

CLASSPATH=`mvn dependency:build-classpath | grep -A 1 "Dependencies classpath" | tail -n1` atom .

[viniciuspires]

@nelsonmenezes Genious solution.

[daw42]

This issue should be resolved by PR #23 . However, we should also make the classpath user-configurable. I suggest we close this in favor of #25

[keplersj]

Closing at the recommendation of @daw42.