-
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
Make it possible to have distributed ProjectRegistry #9848
Conversation
# Conflicts: # ide/che-core-ide-app/src/main/java/org/eclipse/che/ide/context/AppContextImpl.java
…roject' volume defined
…re no 'project' volume defined" This reverts commit 127a79e.
…roject' volume defined
…ode, remove highlighter from the source folder field
@@ -84,4 +86,11 @@ public void shouldUnWatchByMatcher() throws Exception { | |||
|
|||
verify(fileWatcherByPathMatcher).unwatch(ID); | |||
} | |||
|
|||
private static class DummyRootProvider extends 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.
Here will be better use Mock instead of Dummy implementation, this is allow avoid duplication
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.
not sure it simplifies a lot but fixed, thanks )
ci-test |
ci-test build report: |
@@ -189,12 +190,12 @@ | |||
@Inject | |||
public ResourcesPlugin( | |||
@Named("che.jdt.workspace.index.dir") String indexPath, | |||
@Named("che.user.workspaces.storage") String workspacePath, | |||
RootDirPathProvider pathProvider, |
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.
what if keep in constructor
@Named("che.workspaces.storage") String workspacePath
and will use provider for this property
bind(String.class)
.annotatedWith(Names.named("che.workspaces.root.dir"))
.toProvider(RootDirPathProvider.class);
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.
why to make this logic more complex?
what needed is to inject configuration object (called 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.
If you do not mind, I'll put in my five cents. Though technically there is almost no difference between two cases, I find it more comfortable to remember, to navigate and to use (in IDE) RootDirPathProvider
class instead of a variable named "che.workspaces.root.dir" or "che.workspace.storage", it's much easier to access provider class (or property) documentation and so on. Probably it is caused by the way object oriented programmer thinks - in objects and classes, not properties and values.
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.
ок
import org.eclipse.che.api.project.shared.RegisteredProject; | ||
import org.eclipse.che.api.project.shared.dto.RegisteredProjectDto; | ||
import org.eclipse.che.dto.server.DtoFactory; | ||
|
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.
javadoc
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 said it is still experimental impl (kinda placeholder) and not bound yet, of course javadoc will be added
DtoFactory.getInstance().createDtoFromJson(json, RegisteredProjectDto.class)); | ||
} | ||
} catch (Exception e) { | ||
e.printStackTrace(); |
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.
LOG.error ?
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.
ok, will do
|
||
@Inject(optional = true) | ||
@Named("che.user.workspaces.storage") | ||
protected File rootFile = null; |
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.
if you will use constructor injection then you can reuse it in tests.
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.
well, I do not see any blocker for tests, object just need to be prepared according to the contract.
please run |
@skabashnyuk ok, sorry for format but that's what I edited with GH, probably was not a good idea though... |
I'm not sure that issue is only in spaces. I would recommend configuring your ide to use google's formatted and space settings. |
I compared 2 files before commented and yes, only spaces and as I said I used GH editor and what I did is just removing unused comments. |
We can't run selenium test until we have formatting issue. Maven can't compile sources. It has to be fixed somehow. |
@@ -318,8 +319,7 @@ private RegisteredProject doImportInternally( | |||
projectConfigRegistry.put(newProjectConfig, true, false); | |||
} | |||
|
|||
return projectConfigRegistry | |||
.get(wsPath) | |||
return Optional.ofNullable(projectConfigRegistry.getOrNull(wsPath)) |
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 can use return projectConfigRegistry.get(wsPath)
here if I'm not mistaken, but up to you
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.
@RomanNikitenko I guess you are right, just considered it as risky at that time :)
if you or @dkuleshov think it is totally safe - will fix it immediatelly
WDYT?
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 guess we can safely use projectConfigRegistry.get(wsPath)
since it already returns Optional
.
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.
ok, done
@skabashnyuk sure, fixed alltogether |
/** | ||
* Provides path for projects root directory using: env variable 'CHE_PROJECTS_ROOT' (which is set | ||
* by workspace API == "project" volume configured) if not - uses 'che.user.workspaces.storage' | ||
* property otherwise - default with '/project' directory (backward comptible solution) |
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.
typo comptible
- compatible
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.
fair enough :) thanks, fixed
|
||
private final RegisteredProjectFactory registeredProjectFactory; | ||
private final FsManager fsManager; | ||
private final FileCache cache; |
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 would say it isn't a cache but rather a persistence manager.
Beside this I would add cache (basically a map) not to access the fs for every get operations.
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.
@tolusha well, we have this kind of map in default (inmemory, local) registry but an idea is just opposite - to simply reuse a projects volume as a shared for all the machines place (it should be by nature). So it call shared data all the time, not a local map.
So, I'd consider it as a (persisted, not optimized by performance) data cache.
As I said it is experimental and one of the reason is to also learn how it might impact on overall performance. May be it will be OK with this implementation, maybe we can reduce amount of calls, maybe it is not acceptable at all, I do not know yet and would not like to start with complex (data grid like solution) either.
Does it make sense?
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 makes sense for me, thx.
ci-test |
ci-test build report: |
In the functionality that is covered by selenium tests we did not find new regression. We have 4 failed tests which failed in the unexpected place but after rerun they passed as well. |
* Adding pipeline * del jenkinsfile * Make exec agent not to use setsid for other than Linux envs * revert pom.xml * goformat * get projects folder from workkspace configuration * Merge remote-tracking branch 'upstream/master' * clean code * clean code * Fix calculation Projects Root so it wont cause NPE if there are no 'project' volume defined * Revert "Fix calculation Projects Root so it wont cause NPE if there are no 'project' volume defined" This reverts commit 127a79e. * Fix calculation Projects Root so it wont cause NPE if there are no 'project' volume defined * replace provided attribute values with stored (src, out) in PlainJavaProjectType * fix PlainJavaProjectType for getting rid and deprecate using SettableValueProvider * remove comented code * hide brouse source folder button, set source folder field as disabled * hide the browse source button, set source folder field to read only mode, remove highlighter from the source folder field * adapt test for current changes on UI, set save button to enable state * apply formatting * fs cache PT * fix order of steps in the test * Refactor RegisteredProject to make it possible to cache it (as DTO) to local file * cache Projects and PTs to files * Make it possible to have several impls for ProjectRegistry preparing it to be distributed across multi machines env * merge upstream * merge upstream * merge upstream * Update MavenServerService.java * clean code * small fix * small fix * small fix
What does this PR do?
What issues does this PR fix or reference?
as stated in the title
Docs PR
n/a yet