New folders do not register in the jdt.ls workspace #10115 #10665
Conversation
vrubezhny
requested review from
dkulieshov,
tolusha and
vparfonov
as code owners
|
Can one of the admins verify this patch? |
| private void notifyClientOnProjectUpdate(String projectPath) { | ||
| List<Object> parameters = new ArrayList<>(); | ||
| parameters.add(removePrefixUri(convertToJson(projectPath).getAsString())); | ||
| extensionService.executeClientCommand(CLIENT_UPDATE_ON_PROJECT_CLASSPATH_CHANGED, parameters); |
There was a problem hiding this comment.
As for me it is better to initialize CLIENT_UPDATE_ON_PROJECT_CLASSPATH_CHANGED here che/plugins/plugin-java/che-plugin-java-ext-lang-shared/src/main/java/org/eclipse/che/ide/ext/java/shared/Constants.java. che-ls-jdt isn't a good place because it's never used there.
There was a problem hiding this comment.
Yes, it's not used in che-ls-jdt, but still it's a good place to store the constant:
- to reserve its value for the command constant and make it visible for all the users of Commands.java
- to prevent having this command constant value from being re-defined in different plugins for different commands (which is quite possible)
IMHO
| getEntriesFromServer(event.getProject()) | ||
| .then( | ||
| entries -> { | ||
| eventBus.fireEvent(new ClasspathChangedEvent(event.getProject(), entries)); |
There was a problem hiding this comment.
What is the difference between ProjectClasspathChangedEvent and ClasspathChangedEvent? Pls add some javadoc into ProjectClasspathChangedEvent
There was a problem hiding this comment.
Actually, no meaningful difference here..
The problem is that I cannot generate correct parameters for ClasspathChangedEvent in ExecuteClientCommandProcessor.execute(ExecuteCommandParams) (and I think it's not a good place to do that). So, I just notify ClasspathResolver on the fact of changed classpath by using ProjectClasspathChangedEvent, so it can correctly create and fill ClasspathChangedEvent strictly after all server-side modification is finished.
OK. I'll add some javadoc to ProjectClasspathChangedEvent.
tolusha
force-pushed
the
5730_java_ls_poc
branch
from
95fcf33 to
16c5b35
Compare
vrubezhny
force-pushed
the
ls10115-part1
branch
from
09d10ea to
7dca060
Compare
vrubezhny
requested review from
dmytro-ndp,
musienko-maxim and
Ohrimenko1988
as code owners
benoitf
added
status/code-review
Signed-off-by: Victor Rubezhny <[email protected]>
vrubezhny
force-pushed
the
ls10115-part1
branch
from
7dca060 to
0dafa87
Compare
|
I've rebased the PR and resolved conflicts |
benoitf
removed
the
status/code-review
Signed-off-by: Victor Rubezhny <[email protected]>
Signed-off-by: Victor Rubezhny <[email protected]>
Signed-off-by: Victor Rubezhny <[email protected]>
Signed-off-by: Victor Rubezhny <[email protected]>
Signed-off-by: Victor Rubezhny <[email protected]>
Signed-off-by: Victor Rubezhny <[email protected]>
Signed-off-by: Victor Rubezhny <[email protected]>
Signed-off-by: Victor Rubezhny <[email protected]>
Signed-off-by: Victor Rubezhny <[email protected]>
Signed-off-by: Victor Rubezhny <[email protected]>
Signed-off-by: Victor Rubezhny <[email protected]>
Signed-off-by: Victor Rubezhny <[email protected]>
Signed-off-by: Victor Rubezhny <[email protected]>
Signed-off-by: Victor Rubezhny <[email protected]>
Signed-off-by: Victor Rubezhny <[email protected]>
Signed-off-by: Victor Rubezhny [email protected]
What does this PR do?
The PR fixes the workflow of editing the classpath of a plain java project
What issues does this PR fix or reference?
Depends on eclipse-che/che-ls-jdt#66
Release Notes
Docs PR