Provide an InvisibleProjectImporter to handle standalone files

[testforstephen]

Signed-off-by: Jinbo Wang jinbwan@microsoft.com

The original discussion is from the deprecated PR #843.

• add a new InvisibleProjectImporter, that runs after the EclipseProjectImporter.
• If it finds a java file somewhere under the root folder hierarchy. Then:
  • open the file to infer the package.
  • if package matches ancestor folders AND package is fully contained in root folder, then infer a source directory (parent of package dir) and create an invisible project out of it

Currently in order to avoid the deep search of finding the .java source directories, we'll let the LS initialization event to carry the trigger files info. See the PR on vscode-java side redhat-developer/vscode-java#733. Only if the trigger file is java file, AND it's a sub file of current workspace root, then the InvisibleProjectImporter takes effect.

[fbricon]

@testforstephen can you please fix the merge conflicts again?

[fbricon]

So there's a real corner case that fails in vscode:

• open a folder containing standalone java files
• those file don't get the incomplete classpath warning when opened
• open an external standalone java file
• incomplete classpath warning pops up as expected
• call the Clean the Java language server workspace command
• on restart, vscode will reopen the 1st external file, will be declared the triggerfile
• since the triggerfile is external to the root workspace, no invisible project is created
• all standalone files under the root project show the classpath warning

I reckon this is a super weird corner case that is probably ok to ignore, if we can't find a better solution

Another issue:

• directly open the src/ folder of an existing maven or gradle project.
• open on java file underneath it, it will be considered triggerfile
• all java files have compilation errors, because they actually don't have a complete classpath (see my previous comment about it)

There are probably ways to avoid that issue (check ancestor folders have a build descriptor), but that's probably something we can let slide, until someone really complains about it.

Anyways, I think the PR is now in a state where it's actually useful, so, once you fix the conflict, @yaohaizh can merge it

[testforstephen]

Thanks. Agree. We can bring these two issues back to discussion if there are users complaining it.