-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Detect Simple Java Projects on Import #12041
Detect Simple Java Projects on Import #12041
Conversation
ci-test |
Results of automated E2E tests of Eclipse Che Multiuser on OCP: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixing building project with -DskipTests LGTM
Please wait for IDE code owners approvals before a merge
0b384f4
to
cb9a111
Compare
ci-test |
ci-build |
|
||
/** @author Vlad Zhukovskiy */ | ||
@Beta | ||
public class MutableProjectConfig implements ProjectConfig { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not an author of this class in your PR. Besides this class, you leave this one without changes. I'd propose to move MutableProjectConfig
near ProjectConfig
and not having two different implementations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not want to move the class to "shared" because it's not part of the protocolo between wsmaster and the IDE. Removed you as an author.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I see, file located is in wsagent
module, so whats the problem to move implementation to the che-core-api-project-shared
(which also is used by the client)? This will allow us not having two duplicated implementation where one of it is odd. You'll be able to use this class from your code and the client will be able to use it in own purposes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tsmaeder What the problem move it to the shared
? Project API is part of wsagent
and not related to the wsmaster
communications protocol
Results of automated E2E tests of Eclipse Che Multiuser on OCP: |
.getProject(Path.valueOf(project)) | ||
.thenPromise( | ||
projectConfigDto -> { | ||
return projectService |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fields projectService
and promises
become unused in this class and can be removed as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see that some possibly erroneous parts was just moved (not added) however this must not be taken as a justification of adding of a bogus code. At least you can file corresponding issues, for example like you did with improper equals()
method: #12040.
In general, the idea looks just fine for me, however I would like to see what @vinokurig and @vparfonov (who has more expertise in this area) will say.
@@ -227,7 +227,8 @@ public boolean supportGoInto() { | |||
@Override | |||
public boolean equals(Object o) { | |||
if (this == o) return true; | |||
if (!(o instanceof ResourceNode)) return false; | |||
if (o == null) return false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to Eclipse Che Coding Guidelines we are to follow Google Java Style Guide. Please see braces section.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm just doing a minimal fix for the bug here, not rewriting the method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then firstly, why are you fixing the bug here while there already is a separate issue for that #12040?
And secondly, if I remember well, the scale of a fix can't be a reason for a violation of coding guidelines.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm also support that idea, that these changes should be extracted as separated PR according to #12040 if you really think, that there is really a bug.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The fix in equals is needed for fixing this particular issue. If we fix the equals bug, we need to fix it everywhere, which does not work out, priority-wise (we have not scheduled that bug yet).
} | ||
} catch (JsonSyntaxException | InterruptedException | ExecutionException | TimeoutException e) { | ||
LOG.error("Error getting maven projects", e); | ||
} | ||
} | ||
|
||
public void ensureMavenProject(String mavenProjectPath) { | ||
Optional<RegisteredProject> project = projectManager.get(mavenProjectPath); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might consider using org.eclipse.che.api.project.server.ProjectManager#isRegistered
if you only need to check if project is already registered.
...ver/src/main/java/org/eclipse/che/plugin/java/languageserver/JavaLanguageServerLauncher.java
Show resolved
Hide resolved
LOG.info("updating projectconfig for {}", projectPath); | ||
eventService.publish(new ProjectClassPathChangedEvent(project.getPath())); | ||
projectManager.update(project); | ||
} catch (ForbiddenException |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This probably can be shortened to ApiException
, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, APIException is too broad.
List<Object> fixedPathList = new ArrayList<>(arguments.size()); | ||
for (Object uri : arguments) { | ||
String uriString = convertToJson(uri).getAsString(); | ||
String projectPath = removePrefixUri(uriString); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This may lead to errors depending on workspace configuration, please see RootDirPathProvider
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As mentioned above, not part of this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since you have encountered this problem in your work can you please file an issue to keep track of this bug?
this.processorJsonRpcCommunication = processorJsonRpcCommunication; | ||
this.executeCliendCommandTransmitter = executeCliendCommandTransmitter; | ||
this.notifyTransmitter = notifyTransmitter; | ||
this.eventService = eventService; | ||
this.projectManager = projectManager; | ||
this.projectSynchronizer = projectSynchronizer; | ||
this.javaService = javaService; | ||
this.notificationHandler = Executors.newSingleThreadExecutor(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably should configure at least thread name format and exception handler, please see an example
@@ -75,6 +76,9 @@ | |||
private final ProjectManager projectManager; | |||
private final ProjectsSynchronizer projectSynchronizer; | |||
private final AtomicBoolean isStarted = new AtomicBoolean(false); | |||
private final JavaLanguageServerExtensionService javaService; | |||
|
|||
private ExecutorService notificationHandler; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be final
?
...ava/org/eclipse/che/plugin/java/plain/server/inject/PlainJavaProjectSourceFolderWatcher.java
Show resolved
Hide resolved
...va-plain-server/src/main/java/org/eclipse/che/plugin/java/plain/server/ProjectsListener.java
Show resolved
Hide resolved
...ore-api-project/src/main/java/org/eclipse/che/api/project/server/impl/ProjectServiceApi.java
Show resolved
Hide resolved
build-check |
ci-test |
ci-build |
Results of automated E2E tests of Eclipse Che Multiuser on OCP: |
@dkuleshov
Like this one? |
@@ -939,7 +938,6 @@ private void updateProjectsWithProblems(List<String> addedProjectsUri) { | |||
if (!projectConfig.getProblems().isEmpty()) { | |||
try { | |||
projectManager.update(projectConfig); | |||
eventService.publish(new ProjectUpdatedEvent(projectPath)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK this is needed to re-update the project if the project is created before the java language servers started. @tolusha can you confirm it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, we update all projects once the language server has finished starting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, not to re-update the project, but to redraw the project in the project explorer tree.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anyway it causes a bug
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you say what scenario you see going wrong?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not the author of this part of code, so I can't provide scenario when this line will be called. I mean that if we have projectManager.update(projectConfig);
and eventService.publish(new ProjectUpdatedEvent(projectPath));
AFAIK is used to notify the client.
Let me rephrase my question: are you sure that we don't need this line?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or to be more precise: my testing indicates that we don't need this line.
77fd7c4
to
eca85ac
Compare
ci-test |
Results of automated E2E tests of Eclipse Che Multiuser on OCP: |
this.notificationHandler = | ||
Executors.newSingleThreadScheduledExecutor( | ||
new ThreadFactoryBuilder() | ||
.setNameFormat("Jdtls Notification Handler") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.setNameFormat("Jdtls Notification Handler") | |
.setNameFormat("Jdtls Notification Handler-%d") |
ci-test |
Results of automated E2E tests of Eclipse Che Multiuser on OCP: |
26e099e
to
95b41c0
Compare
ci-test |
Results of automated E2E tests of Eclipse Che Multiuser on OCP: |
ci-test |
Results of automated E2E tests of Eclipse Che Multiuser on OCP: |
ci-test |
Results of automated E2E tests of Eclipse Che Multiuser on OCP: |
Signed-off-by: Thomas Mäder <tmader@redhat.com>
Signed-off-by: Thomas Mäder <tmader@redhat.com>
Signed-off-by: Thomas Mäder <tmader@redhat.com>
Signed-off-by: Thomas Mäder <tmader@redhat.com>
Signed-off-by: Thomas Mäder <tmader@redhat.com>
Signed-off-by: Thomas Mäder <tmader@redhat.com>
Signed-off-by: Thomas Mäder <tmader@redhat.com>
95b41c0
to
7b2807f
Compare
What does this PR do?
This PR detects when a project type has been changed to a "Plain Java Project" and creates a project in jdt.ls in turn.
In order for this to work, it was necessary to send ProjectUpdateEvents from where project configs are updated. Unfortunately, ProjectUpdatedEvent was used for other things than just notifying of changes to project configs, so a redesign of the notifications in this area was necessary.
In this cleanup, notifications from jdt.ls to Che have been reduced to "classpath changed" and "maven project created". When che code changes the classpath (e.g. "Use as source folder"), the change is first done in jdt.ls and only propagated back to che through the "classpath changed" notification. Notifications from jdt.ls are handled in a separate thread in order to free up the message receiver thread in case the notification leads to a request to jdt.ls (this was creating deadlock).
What issues does this PR fix or reference?
#11516
Docs PR
This is a bugfix.