Hi everyone,
me and Franz recently sat down and designed the invitation workflow for
Saros/I, how to fit it more naturally to the IntelliJ world than it does
now. The result is attached and also in the Dropbox folder as
"intellij_project_sharing.txt".
(Denis asked for it, I do not know who else would like to check this out).
Best Regards,
Holger
--
Holger Schmeisky; holge...@fu-berlin.de
Takustraße 9, Room 008, Freie Universität Berlin, 14195 Berlin
+49 176 64146306
# Requirements gathering:
* Graham Allen (TIM Group)
- prefer complete window sharing, they often have several modules that
belong together
- In Saros/E they shared several modules as a workaround but this was not
the natural workflow
- contains lots of files that should not be shared but that are not
excluded either
+ they have .gitignore
- no modules outside workspace folder
* Raimo (Vaamo)
- Share whole workspace, because the modules in it are strongly connected
- no modules outside workspace folder
* Thomas Peyrardt (Murex)
- Share whole workspace preferred, because single apps consist of multiple
modules
- maybe modules outside workspace (but not necessary requirement)
* Holger Schmeisky (Zalando)
- sharing whole workspace feels natural
- .gitignore is always present
- modules outside workspace only with Saros, otherwise not
# Saros as Application component
* IntelliJ distinguishes several type of plugin components:
- Application components are created while loading and live without a
window
- each workspace creates own ProjectComponent
- each workspace creates upon first opening a toolwindow (only once, first
time afterwards its only hidden)
* static classes are shared between the projects (it's one VM)
# How Intellij represents modules and projects
* .idea folder defines workspace folder (it is ../.idea)
* .idea contains a modules.xml that lists all modules in the workspace
* Folders are treated as modules when having .iml files and being listed in
the modules.xml
- this also applies to WebStorm etc., they have a single .iml inside the
.idea folder
* projects need the libraries/ folder to work properly, otherwise you get
compile errors
- we can probably assume that nobody who wants to share a project puts
macine-specific information there
# Requirements formulation and design
* Users want to share complete workspaces
* IntelliJ's exclude mechanism works for most of the files that should not be
shared
# suggested design of Saros/I regarding Projects
* create an application component for all components that do not need a
project / workspace (XMPP connection etc.)
* all UI components get created for one workspace
* open problem: sync between several windows of tree (event listener for
XMPP?)
* When a session is started, it is treated as a new workspace
- the guest saros either uses an existing window or creates a new one
- only then, the workspace dependent components are created
# Process for complete project / workspace / Window sharing (the intelliJ
window is equal to the Saros workspace)
This can be implemented in 2 iterations:
1. we assume all workspace files are under the workspace root
2. modules inside a workspace may point to outside the workspace (like the
Saros project currently)
For iteration 1:
Alice starts anywhere and select "Share Project". Saros internally does this:
1 get window's project, its .idea folder and project root
- assuming there is always exactly one, else fail
2 add modules.xml
- assuming there is always exactly one, else fail
3 add .iml files
+ this is to include .imls in the .idea folder (WebStorm)
4 get module paths
5 check if .idea/libraries/ exists
- if yes, add completely
6 add all resources from project folder except excluded resources (for each
module ModuleRootManager.getExcludedRoots )
7 send invitation
On bob's side, receive invitation containing project (file-checksum + project)
1 receive invitation with filelist
2 ask the user to use an existing project or start a new one (similar to when
you open a local project)
3 normal project synchronization
For iteration 2 the following steps are added:s
5a define project root
- if all modules are subfolders of project root, this is the
Saros-Project-Root
+ the advantage is that modules can easily change their status (not
be modules anymore). It would be weird if this changed the Saros-Project-ID
- if there are modules that are neighbor folders of the project root
(e.g. ../core), then their topfolder is the Saros-project root (../ for saros
project layout)
+ this is the root for SPaths
5b create fileAndModuleUnion as prefix-reduced union of Intellij-project-root
+ all auxiliary modules
- this is just the Intellij-project-root if there are no auxiliary modules
- this is the common prefix of auxiliary modules and the workspace, if
there are any (limit at depth 1)
5c normal flow, just replace project by fileAndModuleUnion
On Bob's site
2a select saros-project-root
- for Saros this is saros/, *not* saros/...intellij
* check fileAndModuleUnion for files not present on host, delete them
------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
DPP-Devel mailing list
DPP-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dpp-devel
