Re: [platform-dev] Multi-workspace Eclipse application

2018-04-05 Thread Mickael Istria
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 .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//, 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
> 

Re: [platform-dev] Multi-workspace Eclipse application

2018-04-05 Thread Ed Merks

Mickael,

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.


So many questions arise.  For example, instance preferences are stored 
in the .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?   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//, 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.  :-(


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.  On that front, it seems to 
me that a single workspace can already contain arbitrarily many 
projects. 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.


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.



Regards,
Ed


On 04.04.2018 17:51, Mickael Istria wrote:

Hi all,

In the general idea of improving Eclipse Platform (use case here would 
be JDT-LS) for the cloud, I'm wondering whether some of you already 
considered, tried or evaluated making Eclipse Platform multi-tenant in 
term of workspace, basically having the same instance able to work 
simultaneously with different workspaces, 1 per user/task/whatever ?


Technically -for the public usage-, it would mostly be about avoiding 
references to ResourcePlugin.getWorkspace() in favor of resolving 
workspace according to the context (using for instance 
file.getProject().getWorkspace() instead of 
ResourcePlugin.getWorkspace()) and to introduce a new 
ResourcePlugin.getWorkpace(key) method.


But I imagine it's not so simple and there are more things to 
consider. Hence if someone already have some feedback on this work, 
it'd be greatly appreciated!


Cheers,
--
Mickael Istria
Eclipse IDE  
developer, at Red Hat Developers  
community
Elected Committer Representative at the Eclipse Foundation 
 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


___
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

Re: [platform-dev] Multi-workspace Eclipse application

2018-04-05 Thread Mickael Istria
Hi Szymon,

Thanks a lot for this code, I'll definitely have a look at it!
What I'm interested at this early stage would be answers to this questions,
that the code cannot really capture:
* Do you think this is a doable thing?
* How usable was the proposed code back then? Was it working? What was
missing for it to become mainstream?
* What are the reasons that made this initiative abort? Ie is this for a
technical reason like a blocker was identified? Or was it just abandoned
because it wasn't highest priority back then and never became highest
priority again?

Thanks in advance for your answers, and thanks again for sharing this
precious branch!
___
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

Re: [platform-dev] Multi-workspace Eclipse application

2018-04-05 Thread Szymon Ptaszkiewicz
Hi Mickael,

Multi-workspace idea was already considered a few years ago and there is a
branch which contains the work that happened so far:
http://git.eclipse.org/c/platform/eclipse.platform.resources.git/log/?h=v20100504_MultiWorkspace.
It was created when Eclipse was still on CVS and it is now about 8 years
behind the current master branch, but it should give you a general overview
in what direction the solution was heading.

Best regards,
Szymon

2018-04-04 19:06 GMT+02:00 Pascal Rapicault :

> IIRC I think something along that line has been done in the context of the
> Orion server a long time ago. IIRC John A. worked on this so maybe someone
> from the IBM team can confirm this.
>
> HTH
>
> Pascal
>
> On 4/4/2018 11:51 AM, Mickael Istria wrote:
>
> Hi all,
>
> In the general idea of improving Eclipse Platform (use case here would be
> JDT-LS) for the cloud, I'm wondering whether some of you already
> considered, tried or evaluated making Eclipse Platform multi-tenant in term
> of workspace, basically having the same instance able to work
> simultaneously with different workspaces, 1 per user/task/whatever ?
>
> Technically -for the public usage-, it would mostly be about avoiding
> references to ResourcePlugin.getWorkspace() in favor of resolving workspace
> according to the context (using for instance file.getProject().getWorkspace()
> instead of ResourcePlugin.getWorkspace()) and to introduce a new
> ResourcePlugin.getWorkpace(key) method.
>
> But I imagine it's not so simple and there are more things to consider.
> Hence if someone already have some feedback on this work, it'd be greatly
> appreciated!
>
> Cheers,
> --
> Mickael Istria
> Eclipse IDE 
> developer, at Red Hat Developers 
> community
> Elected Committer Representative at the Eclipse Foundation
>  board of directors
>
>
> ___
> platform-dev mailing listplatform-...@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visithttps://dev.eclipse.org/mailman/listinfo/platform-dev
>
>
>
> ___
> 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
>
___
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

Re: [platform-dev] Multi-workspace Eclipse application

2018-04-04 Thread Pascal Rapicault
IIRC I think something along that line has been done in the context of 
the Orion server a long time ago. IIRC John A. worked on this so maybe 
someone from the IBM team can confirm this.


HTH

Pascal


On 4/4/2018 11:51 AM, Mickael Istria wrote:

Hi all,

In the general idea of improving Eclipse Platform (use case here would 
be JDT-LS) for the cloud, I'm wondering whether some of you already 
considered, tried or evaluated making Eclipse Platform multi-tenant in 
term of workspace, basically having the same instance able to work 
simultaneously with different workspaces, 1 per user/task/whatever ?


Technically -for the public usage-, it would mostly be about avoiding 
references to ResourcePlugin.getWorkspace() in favor of resolving 
workspace according to the context (using for instance 
file.getProject().getWorkspace() instead of 
ResourcePlugin.getWorkspace()) and to introduce a new 
ResourcePlugin.getWorkpace(key) method.


But I imagine it's not so simple and there are more things to 
consider. Hence if someone already have some feedback on this work, 
it'd be greatly appreciated!


Cheers,
--
Mickael Istria
Eclipse IDE  
developer, at Red Hat Developers  
community
Elected Committer Representative at the Eclipse Foundation 
 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


___
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