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 this a biggie, but I think it's necessary to think big once in a
while.
There are other things on a similar scale that I've carrying around for some
time.
I started a Roadmap page to organize these thoughts -- it's not yet linked from
anywhere on saros-project.org, but if you're interested, you can find it here
[3].
The points discussed above fall under the bullet point "Cross-IDE
compatibility".
(You might notice the item "Remove SVN support" -- if we really try to remove
Workspace and Project from the Core, it might be helpful to remove all VCS
stuff
first to get a cleaner starting point.)
Any sort of feedback is welcome.
Cheers,
Franz
[1]
https://github.com/saros-project/saros/commit/09095d4618b765cb249debf46514e5015780e2ca#diff-3a44af4c6edda2824d859d3d5b69bc3d
[2]
https://github.com/saros-project/saros/commit/54ec4ce8622f29bf71c79b28ce4454d230a6e335
[3] http://www.saros-project.org/roadmap
------------------------------------------------------------------------------
_______________________________________________
DPP-Devel mailing list
DPP-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dpp-devel
