Re: [DPP-Devel] IntelliJProjectImpl

[Zieris, Franz]

OK, so to summarize my impressions of your reactions to my proposal to
trim the Core concepts to a minimum:
There are quite a few difficulties along the way, but I did not notice
any fundamental concerns on the topic.

But before we get all too busy starting with just another big rework
activity in Saros, I'd like to finish some of the started topics first,
and make a Saros release.
After that release, we can focus on the "IProject removal".

I'll put some time into the roadmap I recently told you about [1].
I'd like to hear your comments on it -- I'll write another email when
it's time.

In the time being, think of the IProject interface (and IWorkspace) as
quasi-deprecated.
(I don't want to actually annotate "@Deprecated" yet, as this brings
 the total number of Java warnings up from 270 to 738.)
In practical terms: Especially in Saros/I, if you work on something
that currently makes uses of these interfaces, is in some way broken
(due to the concept-mismatch), and can be expressed in another way
(e.g. with IFile, IFolder, or even completely without Saros concepts),
please go that other way.

Cheers,
Franz

[1] http://www.saros-project.org/roadmap

--
___
DPP-Devel mailing list
DPP-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dpp-devel

Re: [DPP-Devel] IntelliJProjectImpl

[Michaela Borzechowski]

Many thanks for all this feedback :)
Ok, so if I understand that right, it's a big task that's going do be done
in the future and nothing I could do right now. I'll just leave it that way
then. I agree with Stefan though and I think I'll write comment to prevent
confusion until it is solved, which sounds like it may take a while.

Michaela

2016-09-20 21:27 GMT+02:00 Matthias Bohnstedt <matthias.bohnst...@gmail.com>
:

> Just a quick addition: I would also not worry to much about the HTLM GUI.
> The (very few) parts that are using IProject or IWorkspace(Root) might
> actually become easier to use if we would only talk in folder, files and
> resources.
>
> Matthias
>
>
>  Ursprüngliche Nachricht 
> Von: "Zieris, Franz" <franz.zie...@fu-berlin.de>
> Datum: 20.09.2016 18:53 (GMT+01:00)
> An: Stefan Rossbach <srossb...@arcor.de>
> Cc: dpp-devel@lists.sourceforge.net
> Betreff: Re: [DPP-Devel] IntelliJProjectImpl
>
> > maybe we had to think about that before we actually start building stuff
> > for theses interfaces, mainly the new HTML interface.
>
> Some thoughts take their time, and sometimes you need to hit a wall at
> full speed to see more clearly.
>
> > As for the core internals, removing the "project" stuff is not that
> > hard. [...]
> > But I do not know yet how this should be accessed from the new HTML Gui.
>
> Funny that you see the difficulties in the HTML GUI;
> I was more afraid of the non-GUI part.
>
> Does this mean we don't need to be afraid of anything, or of everything? ;)
>
> Franz
>
>
> 
> --
> ___
> DPP-Devel mailing list
> DPP-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dpp-devel
>
> 
> --
>
> ___
> DPP-Devel mailing list
> DPP-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dpp-devel
>
>
--
___
DPP-Devel mailing list
DPP-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dpp-devel

Re: [DPP-Devel] IntelliJProjectImpl

[Matthias Bohnstedt]

Just a quick addition: I would also not worry to much about the HTLM GUI. The 
(very few) parts that are using IProject or IWorkspace(Root) might actually 
become easier to use if we would only talk in folder, files and resources.

Matthias


 Ursprüngliche Nachricht 
Von: "Zieris, Franz" <franz.zie...@fu-berlin.de> 
Datum: 20.09.2016  18:53  (GMT+01:00) 
An: Stefan Rossbach <srossb...@arcor.de> 
Cc: dpp-devel@lists.sourceforge.net 
Betreff: Re: [DPP-Devel] IntelliJProjectImpl 

> maybe we had to think about that before we actually start building stuff 
> for theses interfaces, mainly the new HTML interface.

Some thoughts take their time, and sometimes you need to hit a wall at full 
speed to see more clearly.

> As for the core internals, removing the "project" stuff is not that 
> hard. [...]
> But I do not know yet how this should be accessed from the new HTML Gui.

Funny that you see the difficulties in the HTML GUI;
I was more afraid of the non-GUI part.

Does this mean we don't need to be afraid of anything, or of everything? ;)

Franz 


--
___
DPP-Devel mailing list
DPP-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dpp-devel
--
___
DPP-Devel mailing list
DPP-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dpp-devel

Re: [DPP-Devel] IntelliJProjectImpl

[Stefan Rossbach]

Well, about 700 errors so for when removing the IProject interface 8-)

I think the hardest part is the SPath stuff, as we have to ensure, that 
a path is now transmitted as an absolute path.

I will present a (of course broken) patch set next week.


On 20.09.2016 18:53, Zieris, Franz wrote:
>> maybe we had to think about that before we actually start building stuff
>> for theses interfaces, mainly the new HTML interface.
> Some thoughts take their time, and sometimes you need to hit a wall at full 
> speed to see more clearly.
>
>> As for the core internals, removing the "project" stuff is not that
>> hard. [...]
>> But I do not know yet how this should be accessed from the new HTML Gui.
> Funny that you see the difficulties in the HTML GUI;
> I was more afraid of the non-GUI part.
>
> Does this mean we don't need to be afraid of anything, or of everything? ;)
>
> Franz
>


--
___
DPP-Devel mailing list
DPP-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dpp-devel

Re: [DPP-Devel] IntelliJProjectImpl

[Zieris, Franz]

> maybe we had to think about that before we actually start building stuff 
> for theses interfaces, mainly the new HTML interface.

Some thoughts take their time, and sometimes you need to hit a wall at full 
speed to see more clearly.

> As for the core internals, removing the "project" stuff is not that 
> hard. [...]
> But I do not know yet how this should be accessed from the new HTML Gui.

Funny that you see the difficulties in the HTML GUI;
I was more afraid of the non-GUI part.

Does this mean we don't need to be afraid of anything, or of everything? ;)

Franz 


--
___
DPP-Devel mailing list
DPP-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dpp-devel

Re: [DPP-Devel] IntelliJProjectImpl

[Stefan Rossbach]

Hi Franz,

maybe we had to think about that before we actually start building stuff 
for theses interfaces, mainly the new HTML interface.

As for the core internals, removing the "project" stuff is not that 
hard. If you remove projects you will end up with partial sharing.

What is left is to figure out when a project-, module,- whatever 
reference is required.

Creating projects, modules etc. should then be part of the specific 
plugin implementations. But I do not know yet how this should be 
accessed from the new HTML Gui.

BR,

Stefan

On 20.09.2016 18:30, Zieris, Franz wrote:
> Hi there,
>
> Michaela started by asking:
>
>> In IntelliJ and Eclipse a "Project" is a different thing.
>> A project in Eclipse is like a module in IntelliJ.
> Yes, "like" is the correct verb. But not "equal" and that's causing some 
> trouble.
>
>> Now there is the class IntelliJProjectImpl, and I was wondering,
>> whether it shouldn't be named IntelliJModuleImpl instead to prevent 
>> confusion.
> It's called "ProjectImpl" because it "implements" the core interface 
> "IProject".
> So renaming the class would solve part of the confusion, just to create 
> another one.
>
>> The question I have is, whether the class is really only used to model a 
>> module.
> The technical answer is: It is used (or *should* be used) whenever you make 
> use
> of Core functionality that requires an IProject parameter (or returns an 
> IProject value).
> For everything else it's a good idea to stick with Intellij concepts and data 
> types.
>
> Stefan answered:
>
>> IWorkspaceRoot represents an IntelliJ project. [...]
>> Maybe add some documentation to the class [IntellijProjectImpl],
>> that it represents a module internally.
> I'd rather solve this on a more fundamental level, see below.
>
> Etienne added:
>
>> IMHO this class should represent a project.
>> Only sharing a module is not a Real choice as far as i know,
>> and it's a pain when trying to work with Saros/I.
> Eventually, Saros should be able to share what the user wants to share.
> So, yes: Limiting Saros/I to single modules is not the target state,
> but it's a reasonable step along the way.
>
> Story time:
> - Initially, Saros supported only single (and complete) Eclipse projects.
>SharedProject was the old name of Session (until about six years ago [1]).
> - We realized, that limiting Saros to a single Eclipse project was not the
>way to go. After all, Saros *itself* is made up out of multiple Eclipse
>projects. Sharing multiple projects was implemented in early 2011;
>partial sharing (= arbitrary subsets of project resources) was added in
>late 2011.
> - At this point, Saros should have been reworked so that projects are only
>a convenient way of selecting resource collections, but nothing more.
>In particular, projects should have no longer been an integral element
>of Saros's business logic.
> - But, alas, years went by, and  The Project  remained the unit of all
>Saros sessions. Up until the day we started the Saros/I implementation
>and created Eclipse look-a-like interfaces in the core two and half years
>ago [2] -- simply because we did not know what the Intellij requirements
>would be, so this was the easiest way to go.
>
> So what now?
> - We could rename the core interfaces to something generic, using terms
>that are neither from the Eclipse, nor from the Intellij realm. Something
>like: TheThingContainingEverything instead of IWorkspaceRoot and
>UnitsOfCode instead of IProject.
>This way, confusion would be less likely, because you're not tempted to
>think in IDE terms.
> - But what would be the point? From a user's perspective, all we really
>care about are files and folders, and everything that we need to 
> synchronize
>those copies is some reference point to calculate the relative paths to.
> - Furthermore, even if we could find generic names, there would be no actual
>concepts behind them. A few examples:
>- An Eclipse Workspace is a loosely coupled collection of projects;
>  an IntelliJ Project consists of closely coupled Modules.
>- Eclipse users are not likely to have more than one Eclipse instance
>  opened at the same time; IntelliJ users happen to do so (at least I've
>  seen it a few times).
>- An Eclipse Project only contains files and folders; an IntelliJ Module
>  itself may contain more Modules.
>
> So my proposal is as follows:
> - On a technical level, the Core filesystem package should not know about
>anything but Resources, which are either Files or Folders, which in turn
>contain more resources. That's the intersection of the two concept worlds.
> - From a user perspective, Saros should be able to share any collection of
>resources -- the participants need to agree on a reference point, and
>Saros does the rest.
>- In an E/E setting there would nothing wrong to let the users still select
>  projects on the 

Re: [DPP-Devel] IntelliJProjectImpl

[Zieris, Franz]

Hi there,

Michaela started by asking:

> In IntelliJ and Eclipse a "Project" is a different thing.
> A project in Eclipse is like a module in IntelliJ.

Yes, "like" is the correct verb. But not "equal" and that's causing some 
trouble.

> Now there is the class IntelliJProjectImpl, and I was wondering,
> whether it shouldn't be named IntelliJModuleImpl instead to prevent confusion.

It's called "ProjectImpl" because it "implements" the core interface "IProject".
So renaming the class would solve part of the confusion, just to create another 
one.

> The question I have is, whether the class is really only used to model a 
> module.

The technical answer is: It is used (or *should* be used) whenever you make use
of Core functionality that requires an IProject parameter (or returns an 
IProject value).
For everything else it's a good idea to stick with Intellij concepts and data 
types.

Stefan answered:

> IWorkspaceRoot represents an IntelliJ project. [...]
> Maybe add some documentation to the class [IntellijProjectImpl],
> that it represents a module internally.

I'd rather solve this on a more fundamental level, see below.

Etienne added:

> IMHO this class should represent a project.
> Only sharing a module is not a Real choice as far as i know,
> and it's a pain when trying to work with Saros/I.

Eventually, Saros should be able to share what the user wants to share.
So, yes: Limiting Saros/I to single modules is not the target state,
but it's a reasonable step along the way.

Story time:
- Initially, Saros supported only single (and complete) Eclipse projects.
  SharedProject was the old name of Session (until about six years ago [1]).
- We realized, that limiting Saros to a single Eclipse project was not the
  way to go. After all, Saros *itself* is made up out of multiple Eclipse
  projects. Sharing multiple projects was implemented in early 2011;
  partial sharing (= arbitrary subsets of project resources) was added in
  late 2011.
- At this point, Saros should have been reworked so that projects are only
  a convenient way of selecting resource collections, but nothing more.
  In particular, projects should have no longer been an integral element
  of Saros's business logic.
- But, alas, years went by, and  The Project  remained the unit of all
  Saros sessions. Up until the day we started the Saros/I implementation
  and created Eclipse look-a-like interfaces in the core two and half years
  ago [2] -- simply because we did not know what the Intellij requirements
  would be, so this was the easiest way to go.

So what now?
- We could rename the core interfaces to something generic, using terms
  that are neither from the Eclipse, nor from the Intellij realm. Something
  like: TheThingContainingEverything instead of IWorkspaceRoot and
  UnitsOfCode instead of IProject.
  This way, confusion would be less likely, because you're not tempted to
  think in IDE terms.
- But what would be the point? From a user's perspective, all we really
  care about are files and folders, and everything that we need to synchronize
  those copies is some reference point to calculate the relative paths to.
- Furthermore, even if we could find generic names, there would be no actual
  concepts behind them. A few examples:
  - An Eclipse Workspace is a loosely coupled collection of projects;
an IntelliJ Project consists of closely coupled Modules.
  - Eclipse users are not likely to have more than one Eclipse instance
opened at the same time; IntelliJ users happen to do so (at least I've
seen it a few times).
  - An Eclipse Project only contains files and folders; an IntelliJ Module
itself may contain more Modules.

So my proposal is as follows:
- On a technical level, the Core filesystem package should not know about
  anything but Resources, which are either Files or Folders, which in turn
  contain more resources. That's the intersection of the two concept worlds.
- From a user perspective, Saros should be able to share any collection of
  resources -- the participants need to agree on a reference point, and
  Saros does the rest.
  - In an E/E setting there would nothing wrong to let the users still select
projects on the sender's side and warn the recipient if s/he is about
to select a non-project as the root. 
  - The same goes for S/S sessions. Just because the Core logic only talks
about files and folders, the IDE plugins that make use of the Core do
not need to refrain from any form of usability.
  - In cross-IDE sessions, the users need to figure out a way of how to
structure their code and what to use as the reference point for their
session. But if they use a version control system, they need to figure
out the first part anyway (just as we did with both Eclipse and Intellij
metadata in our most important projects).
- In fact, getting rid of Workspace and Projects in the core is the only way 
  I see to enable cross-IDE session in the long run.

I know that 

Re: [DPP-Devel] IntelliJProjectImpl

[Etienne Girard]

Hi Michaela,

IMHO this class should represent a project. Only sharing a module is not a
Real choice as far as i know, and it's a pain when trying to work with
Saros/I.

Regards,
Etienne

Le 20 sept. 2016 15:57, "Michaela Borzechowski" 
a écrit :

> Hey all,
>
> In IntelliJ and Eclipse a "Project" is a different thing. A project in
> Eclipse is like a module in IntelliJ. Now there is the class
> IntelliJProjectImpl, and I was wondering, whether it shouldn't be named
> IntelliJModuleImpl instead to prevent confusion. The question I have is,
> whether the class is really only used to model a module. It certainly is
> used for a module implementation in ShareWithUserAction, but does anyone
> know if it is used to model a project somewhere?
>
> Thanks
> Michaela
>
> 
> --
>
> ___
> DPP-Devel mailing list
> DPP-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dpp-devel
>
>
--
___
DPP-Devel mailing list
DPP-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dpp-devel

Re: [DPP-Devel] IntelliJProjectImpl

[Stefan Rossbach]

Hi Michaela,

IWorkspaceRoot represents an IntelliJ project. Maybe you should do a 
little refactor in the ShareWithUserAction class to make it clear that 
you are using modules and projects in IntelliJ but when you have to 
access the core, you have to "convert" an IntelliJ module to a core project.


So I would stick with the name IntelliJProjectImpl as it is. Maybe add 
some documentation to the class, that it represents a module internally.


On 20.09.2016 15:57, Michaela Borzechowski wrote:

Hey all,

In IntelliJ and Eclipse a "Project" is a different thing. A project in 
Eclipse is like a module in IntelliJ. Now there is the class 
IntelliJProjectImpl, and I was wondering, whether it shouldn't be 
named IntelliJModuleImpl instead to prevent confusion. The question I 
have is, whether the class is really only used to model a module. It 
certainly is used for a module implementation in ShareWithUserAction, 
but does anyone know if it is used to model a project somewhere?


Thanks
Michaela


--


___
DPP-Devel mailing list
DPP-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dpp-devel


--
___
DPP-Devel mailing list
DPP-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dpp-devel