Hi Ed, Thanks for sharing those concerns, I'll try to propose some possible solutions inline. As a preamble note, this is an idea revived in the context of jdt.ls and cloud deployment of an IDE to multiple users; I'm not trying to change anything in regular and legacy single-user desktop IDEs -which do work great as it and for which multi-worspace wouldn't help at all-.
Sorry, but my knee-jerk reaction is very negative. Just imaging the number > of places in my own frameworks that would need to be reworked gives me cold > shivers. Imagining trying to maintain compatibility between a > before-multiple-workspaces Eclipse and an after-multiple-workspaces Eclipse > makes the cold shivers worse. > As usual, any change should be backward compatible to minimize, and even annihilate, the need for specific adoption for downstream projects. > So many questions arise. For example, instance preferences are stored in > the <workspace>.metadata folder because of course they're per-workspace > preferences. So as a user, when I change a preference, in which workspace > would be be stored? > The use-case I have in mind for multi-workspace is definitely not the Eclipse IDE or SDK which is better remaining a single user/workspace app. It's more for cloud deployments, like jdt.ls in Eclipse Che, where multi-tenancy can lead huge savings of energy/dollars/hardware... Those would be for future specific applications that want to allow such multi-workspace mechanism. I don't expect nor want legacy apps like the IDE should change behaviour by default. So everything would remained stored the same way in all existing apps which would use the "default" workspace of the application, as selected by user. > Also, often code in any specific framework really has no context, at least > not currently. E.g., when EMF saves a resource with the URI > platform:/resource/<path>/<file>, it uses a utility like the following, > of course assumes there is but one workspace with one workspace root: > IFile file = workspaceRoot.getFile(new Path(platformResourcePath)); > What if there are multiple workspaces and each one has a corresponding > IFile for that URI? To me the questions of "how would that work?" seem > endlessly endless. :-( > Similar issues should already exist file.getPath() and other existing methods in current implementation. I have no real knowledge (yet?) how this can work in a backward compatible way. I imagine the simpler is that apps that would support multiple workspaces declare it early before starting any workspace to "enable" the new things, and maybe change the behavior of some methods when workspaces are qualified or something like that. For example, the path URI could be turned in the form of "platform:/resource/workspaceId/path/file" and the various possible method be able to support such path/URIs when multiple workspaces are on... Apps that wouldn't declare support for mulitple-workspace should remain on the exact same behavior. > It seems to me there are so many other places where effort to improve > things could/would be better focused. But in the end, the fundamental > question, "What does such a new feature buy us that would offset the huge > disruption?", needs a very good answer. > If we want Eclipse Platform and jdt.ls and many other to remain relevant in Cloud IDE, we do need it. Without multi-tenancy or other way to save a lot of resources when multiple users want Java support in their Cloud IDE, then jdt.ls is very expensive in term of resources for cloud deployment, and Java will become a very expensive language to have devtools in the cloud. As a result, many vendors will favor leaner stacks or stacks which have more scalable language servers, users will go using the recommended stacks (which wouldn't be Java and Eclipse-based ones), and the investment in Eclipse Platform and Java will decrease. It seems to me, based on the current market of DevTools and the strategy of my employer, that offering multi-tenancy will eventually become a requirement to keep Eclipse relevant in the cloud IDEs world. > On that front, it seems to me that a single workspace can already contain > arbitrarily many projects. > Sure, but they're not isolated between users. I want projects from user A to not be accessible to user B. Moreover, I want user A and user B to work on different versions of the same project. > As such, an operation/action where one could specify "Import Projects from > Other Workspace" could accomplish much the same goal, wouldn't it? I.e., > it seems to me the goal, which I assume is to have a workspace with more > projects it in, might be better directed toward a utility for composing > multiple workspaces into a single workspace. This could be accomplished > with no disruption to anyone else because the end result is simply a single > workspace. > Unless I missed something, this proposal doesn't work for the requirement above. > So that's my feedback. Try to clearly articulate goal. It seems to me > that "multiple workspaces" is a way to achieve some goal, but is not really > the goal in and of itself and may well not be the best way to achieve the > real underlying goal. > Thanks for the feedback. I hope my answers did clarify the goal here. Feel free to ask again and again until I didn't manage to make myself clear about the "why", I really appreciate your feedback. -- Mickael Istria Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/> developer, at Red Hat Developers <https://developers.redhat.com/> community Elected Committer Representative at the Eclipse Foundation <https://www.eclipse.org/org/> board of directors
_______________________________________________ platform-dev mailing list platform-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/platform-dev
