Designing and Implementing IDE Cross-Compatibility for Saros
worked on by: Tobias Bouschen
due by: 2020-06-30 (CW 27) Moved back due to Corona Pandemic (
FU announcements)
due by: 2020-11-09 (CW 46)
initial presentation slides:
PDF
Outline
Saros is a plugin designed for distributed pair programming
*.
Its goal is to provide the technical infrastructure for developers to concurrently collaborate on shared resources without being co-located.
Furthermore, it provides the benefit of allowing the users to work in their usual work environments (IDEs) using their own configuration, thereby potentially increasing the productivity of pair programming sessions.
Saros was initially only designed for Eclipse, but later on was adjusted to also be available for other IDEs as well (mainly IntelliJ, but support for other IDEs would also be possible and was/is being worked on by other theses).
The introduction of additional implementations for other IDEs broadened the usability and potential user base of Saros but also led to a new difficulty: Saros implementations for different IDEs were not cross-compatible.
Providing such cross-IDE compatibility would further increase the benefit of allowing the users to work in their usual environment by bridging the gap between different IDE users, thereby furthermore broadening the potential user base and use cases for Saros.
If you are not familiar with pair programming, you can read this
recent article from Martin Fowler about it.
Goal of the Thesis
The goal of this thesis is providing IDE cross-compatibility capabilities for the Saros plugin.
To make it more approachable, I split it up into the following sub-goals:
- Analyze the current state of the Saros plugin and its IDE implementations.
- Identify potential roadblocks on the way to supporting IDE cross-compatibility.
- Resolve the necessary roadblocks.
Previous theses already worked on the related topic of extracting the core business logic into a separate package, the Saros Core:
Furthermore, this work was also continued through non-thesis-work by multiple Saros contributors over the years.
The process of creating a better IDE abstraction was also started more recently with the master's thesis
"Saros: Refactoring the Filesystem" by Oliver Hanßen (2019) (
written in German), which worked on providing a basic design for making the filesystem implementation IDE independent by moving to a reference point system.
As an almost all-encompassing work on Saros, a general overview of the field of agile development and pair/party programming as well as Saros, its development history, how it compares to other, related tools, and a detailed analysis of the design of Saros measured under the viewpoint of usability in an industrial setting is given in the dissertation
"Industrially Usable Distributed Pair Programming" by Julia Schenk (2018).
Issues With Cross-IDE Compatibility
Saros was initially designed solely as an Eclipse plugin.
As other IDE implementations were never planed, the interface and software architecture design was heavily based on Eclipse models to make the integration as easy as possible.
Later on, the idea of providing Saros implementations for other IDEs gained traction, leading to substantial efforts being made to extract any IDE-independent Saros business logic into a separate component, the Saros Core.
But the basic design and architecture of the logic was not adjusted, leading to a situation where the Saros Core components still contain many assumptions of how different IDE concepts work that are heavily based on the Eclipse model.
As a result, implementing Saros for other IDEs is not as easy as it could be.
Some aspects of the Core interfaces are still closely modeled after Eclipse counterparts, leading to issues when trying to implement them for other IDEs.
An important additional factor for this thesis is that I make sure that my knowledge of the Saros/I implementation and the used IntelliJ APIs does not influence the design process in a similar manner. Otherwise, the resulting architecture could suffer from the same issues as the current one.
Milestones and Planning
| # |
Past |
Date |
CW |
Goals |
| 1 |
✅ |
28.01.20 |
CW05 |
A basic overview over the Saros architecture and possible roadblocks has been achieved |
| 2 |
✅ |
21.02.20 |
CW08 |
A list of steps to take on the way to implementing IDE cross-compatibility has been compiled |
| 3 |
✅ |
27.06.20 |
CW26 |
The Saros filesystem interface has been revamped |
| 4 |
✅ |
27.06.20 |
CW26 |
Basic IDE cross-compatibility has been implemented |
The list of steps to take on the way to supporting IDE cross-compatibility is quite extensive. The milestone of having refactored the filesystem handling is quite arbitrary and was chosen before the list of steps was defined. However, as the refactoring is probably the largest single task, it still offers a good milestone to compare progress against. The list of milestones might still be adjusted during the process of working on the defined steps.
Milestone 1 – Roadblocks
To identify roadblocks, I had a general look through the existing packages and classes in the Saros Core, Saros/E and Saros/I. Furthermore, I encountered some of these issues while working on Saros/I.
Initially, I have identified the following roadblocks:
- The Handling of Editor Contents
- The Handling of Modules/Project
- Determining Which Resources to Share
Roadblock 1 – The Handling of Editor Contents
With the current operating systems, there are two different ways of signaling the ending of a line in a text file:
\n for UNIX-based operating systems and
\r\n for the Windows operating system.
In Eclipse, like in most IDEs and editors, the line ending written in the file are also used when processing it internally or representing it in the editor.
In IntelliJ, however,
line endings are normalized to UNIX line endings internally.
All line endings in the file are substituted with the UNIX line ending when it is read from disk and the original line endings are then re-substituted when the content is written back to disk.
This poses a big issue for IDE cross-compatibility as, even when working on the same content on disk, the document content available in the IDE does not have to match.
In particular, when trying to maintain a session between an IntelliJ instance and an Eclipse instance running on Windows, Saros will always detect an inconsistency in the shared files as the line endings will not match.
Furthermore, as the two line separators are not of equal length, the UNIX line separator consisting of one character and the Windows line separator consisting of two characters, the character-based offsets will be different in the two files.
This poses another challenge for Saros, which relies heavily on such offsets to apply remote changes correctly and display awareness information such as remote cursor locations and selections.
Roadblock 2 – Issues With the Current Project/Module Handling
Different IDEs use different models to represent the structure of the aggregates of files representing a piece of software.
As Saros wants to interact with these files, it needs to be able to interface with this logic.
Since Saros was first only designed for Eclipse, the interface to interact with the filesystem logic matches the Eclipse counterpart, going so far as to simply refer to the Eclipse documentation if no other explicit documentation was given for a method or class.
The design was also not amended when extracting the logic to the Saros Core, meaning it was still very much based on the Eclipse counterpart.
This makes the implementation of Saros for other IDEs more cumbersome as the IDE-specific filesystem interface has to be somehow mapped onto the Saros (or rather Eclipse) filesystem interface.
Even when such a mapping is possible, the underlying implementation still has to be IDE specific to match the IDE filesystem model.
This can lead to a confusing mix of names and concepts in the implementation, especially when naming schemes clash in the different IDE concepts, an example being
the usage of the term "project" in the Eclipse and IntelliJ model.
Though this issue with mapping new IDE implementations onto the Core interface is cumbersome when implementing Saros for new IDEs, it does not provide as much of an issue for IDE cross compatibility.
A more pressing issue is that the current sharing logic uses IDE-specific concepts to determine the files to share with other participants.
Saros for Eclipse allows the user to share
projects while Saros for IntelliJ allows the user to share
modules.
While these concepts are generally comparable in scope, it is not always possible to create a clean mapping between Eclipse projects and IntelliJ modules for the same piece of software as the filesystem models of Eclipse and IntelliJ are far to different.
This especially becomes an issue when trying to create a project/module as part of a cross-IDE Saros session as the other IDE models won't necessarily provide all the information necessary to correctly represent it in the local model.
These complications grow with the complexity of the shared project/module setup.
As an example, even with a relatively normal setup, like the Saros project itself, a mapping between Eclipse projects and IntelliJ modules is far from trivial:
Eclipse sees each Saros component (e.g. Core, Eclipse, IntelliJ) as one project.
IntelliJ, on the other hand, imports every Saros component through Gradle as three modules, each containing different parts of the tree: a base module containing the general resource tree, a "main" sub-module containing only the source roots and resources, and a "test" sub-module containing only the test roots and resources.
As a result, there is no clean mapping between Eclipse and IntelliJ as the same resources that are represented by one project in Eclipse are spread across three modules in IntelliJ.
Furthermore, some of these IntelliJ modules can't be represented as a unified tree (without including parents outside the module) as they are the combination of different resource trees.
There is no way of representing such a collection of resources as a single project in Eclipse.
Roadblock 3 – Determining Which Resources to Share
Generally, projects/modules contain resources that should not be shared through Saros, examples being automatically generated artifacts or files containing user specific data.
A good definition for most of these files would be "files that should not be kept under versioning", i.e. that should be ignored by the used version control system (e.g. Git, Subversion, etc.).
The current approach of Saros is to use local IDE mechanisms to determine which resources not to share.
Most IDEs offer the option to ignore resources like build artifacts in the local workspace in order to exclude them from functionalities like inspections, searches, and refactoring tools.
Eclipse offers the concept of
derived resources and IntelliJ the concept of
excluded resources for this purpose.
The issue with this approach is that, in both cases, these concepts are generally only used to mark resources that are generated as part of the compilation process.
However, there also are other automatically generated resources and resources that contain user specific data that should not be shared between Saros instances.
When implementing Saros to only work for one specific IDE, it is quite simple to cover most of these special cases with dedicated logic to exclude such resources as most of them can be queried from the IDE.
But this only works if the set of non-shared resources determined through the IDE specification is the same for all participants.
If participants use different IDEs, the set of such additional non-shared resources might vary between the participants, leading to a perceived desynchronization as Saros detects files for some participants while they are ignored for others.
Milestone 2 – Steps
Initial, I created a list of steps necessary in order to reach IDE cross-compatibility.
These steps offered a good jumping-off point but were to vague to be solely relied on during the implementation phase. Instead, I proceeded in an agile fashion, deciding on what to do next in an ad hoc fashion.
A good overview of the implementation process is given in the
work log.
Work Log
Preparation
Activities
- discussing the topic and scope of the thesis with Lutz Prechelt and Kelvin Glaß
- searching for and reading relevant literature:
- Topic – Saros Design
To get a better understanding of the Saros features, their purpose, and the design thought behind them, I read the provided base literature on the Saros design and history (see below). This base knowledge is essential when having to make the decision whether or not to cut a feature to allow for (easier) IDE cross-compatibility, as reducing the usability of Saros should (largely) be avoided.
- Topic – Reference Points
I also looked for general articles about the usability of (distributed) pair programming tools but was not able to find many sources that brought new information to the table. Most of the important information is already given in the dissertation from Julia Schenk (which also references the sources it uses).
Week 00 + 01 (CW 03+04)
currently working on milestone 1
Activities
- skimmed through Saros codebase
- created preliminary list of roadblocks (see milestone 1)
- requested feedback on Saros developer mailing list
- working together with other developers is very important to design something that can actually be integrated into the codebase
- asking for help from developers with in-depth knowledge of the Saros/E codebase to figure out implementation specific differences between Saros/E and Saros/I
- looked ad VSCode API to gather information about internal workings and possible compatibility issues
- so far unsuccessful as API documentation is ok but there is no documentation about base concepts/assumptions
Results
- updated list of roadblocks on this page
Next Steps
- discussing the list of preliminary roadblocks with other Saros developers
Problems
Week 02 (CW 05)
currently working on milestone 1 and 2
Activities
- discussed cross-compatibility issues with other Saros developers on separate occasions (Stefan and Kelvin)
- decided to remove the milestone 2 "The basic design for Saros IDE cross-compatibility is complete" from the agenda as it is too general
- the basics are already covered by the list of roadblocks
- any other issues that may arise on the way to IDE cross-compatibility will most likely be very IDE implementation dependent, meaning they are hard to foresee
- created an initial plan on how to proceed implementing solutions for the found roadblocks (see milestone 2)
- added detailed description for every step of the plan describing what has to be done and some of the though behind the step
- found additional roadblock 4
- cleared up general design of future Saros architecture
- as shown by the difficulties caused by a lack of such a general overview, specifying the desired architecture might still be necessary/useful after all
- cleared up misconception about difficulties dealing with normalized encodings
- as we are sharing document content changes by using their String representation, the content was already normalized to using Unicode characters
- this removes the need to care about the conversion ourselves, the only remaining issue is what to do on remote file creation
- searching for a good way of determining whether a file is binary or not
Results
- finalized initial list of roadblocks
- created list of steps on the way to IDE cross-compatibility
- improved planned design of new Saros architecture
Next Steps
Problems
- scope of thesis/feature set of Saros is still not completely clear
- this is most likely due to the missing user feedback and knowledge what the general use case for Saros should be
- did not have a clear view of the desired Saros architecture, leading to issues while planning/designing the adjustment of Saros for IDE cross-compatibility
- wanting to please all possible users/cover all use cases is nearly impossible in this scenario and at least not feasible in the scope of this thesis
- making the decision of cutting features/use cases is hard without a good knowledge of the user base or desired use case
- determining whether or not a file is binary is quite complicated
Week 03 (CW 06)
*currently working on milestone
2
Activities
- changed stance on binary handling to use IDE logic
- could not find library handling detection of binary files
- implementing logic myself seems like to much work (as there are many corner cases) and still requires to much guess work to be reliable
- IDE logic should be usable in most cases as misconfiguration would also mean that the file can not be worked on in IDE
- updated step 1 to reflect new plan
- adjusted step 5 to also include the adjustment of the recovery logic
- adjusted step 5 to include more details regarding the handling of mismatched binary detection
- re-added the option of using locally excluded/derived resources of the host to determine what not to share
- implemented adjustment needed for step 1 but was stopped by architectural questions:
- how should we handle editors for binary files?
- skimmed over code to get a basic idea on how to implement the logic needed for step 5
- started writing basic "design" for Saros (i.e. what should be able to Saros do, what are its core capabilities)
- implemented prototype normalization bridge
- noticed likely performance problems as a result of having to read the entire text up to the offsets for offset correction when sending and receiving selection activities
- better solution would be to switch activities to sending line and in-line offset instead of global offset; allows to skip offset normalization
Results
- created initial list of steps to take (see milestone 2)
- developed initial prototype ideas for different steps and discovered issues with some of the steps
- created initial feature set/design for Saros
Next Steps
- discuss "feature set"
- re-work initial list of steps
Problems
Week 04 (CW 07)
currently working on milestone 2
Activities
- prepared and held initial presentation
- further discussed handling of encodings and line endings
- reached consensus that encoding should be determined by creator of resource, line endings by local IDE settings (i.e. follow git handling)
Results
- presentation (see slides)
- noticed (during presentation discussion) that offset correction also needs to apply to text operations
- see Problems section for more on this
Next Steps
- update roadblock and steps section
- read base literature on Jupiter algorithm and operational transformation
- gain general over logic that needs to be adjusted in order to also use the new offset coordinates (line number + in-line offset) for text operations
- determine whether such a text operation offset adjustment is a reasonable approach considering the complexity of the necessary changes
Problems
- offset correction for text operations means that the Jupiter algorithm and operational transformation logic in the core needs to be adjusted as well
- hoped that this could be avoided as they are important parts of the logic, very complex, and not that well understood by the current developers in the project (myself very much included)
Week 05 (CW 08)
currently working on milestone 2
Activities
- looked at Saros Core concurrency implementation
- checked usage of operation position to ensure move to new position scheme (line number + in-line offset) is plausible
- read base literature on Jupiter algorithm: "High-Latency, Low-Bandwidth Windowing in the Jupiter Collaboration System"
- finished planning process for list of steps
- started working on unifying handling of non-text editors for Saros/E and Saros/I
Results
- improved understanding of Jupiter algorithm design and our implementation
- ensured adjustment of position scheme (line number + in-line offset) is compatible with the Jupiter algorithm
- adjusted list of steps
Next Steps
Problems
Week 06 (CW 09)
currently working on milestone 2 & 3
Activities
- worked on unifying handling of non-text editors for Saros/E and Saros/I
- did testing on non-binary vs. opened in non-text editor (see Problems)
- started working on migration of offset based activities to position based activities
- started with selection annotations
- encountered problems with being reliant on editor to make conversion (see Problems)
Results
- created PR #842
- decided to stick to line based selection model
- will implement caching of line number <-> offset mapping if performance becomes an issue
- created initial prototype for selection handling migration to position based logic
- refined initial prototype to make it ready to be proposed as a PR
Next Steps
- get PR #842 reviewed and merged
- create PR for selection refactoring
Problems
- discovered that the concepts of binary and not openable in a text editor are not the same thing
- e.g. class files are opened in a text editor for IntelliJ
- local logic calculating line number <-> offset needs editor
- if no editor is present, requires manual calculation
- can be sped up by caching offset <-> line number mapping, but this requires a lot of additional logic and requirements to the base logic (i.e. activities need to be processed linearly, even selection and text edits)
- handling of base logic in Saros/E and Saros/I is more different than initially thought
- handling of background changes without an open editor
- handling of file moves/renames and the handling of caused text changes
Week 07 (CW 10)
currently working on milestone 3
Activities
- refined initial prototype for moving to a line base selection model
- improved PR #862 according to review comments
- decided to not merge the PR until at least the prototype for the text edit handling is complete, meaning the approach of using the new positioning scheme is valid
- worked on prototype for refactoring the text edit handling to use the new positioning scheme
- adjusted initial design by shifting to a line delta and offset delta model for operations
- operation is defined through start position, line delta, offset delta, and text
- makes it easy to calculate end positions on the fly, even with changing start positions
- offsets could always be calculated from text on the fly, but this would be time intensive and would require us knowing the used line separator (or guess it)
- found issue in split operation combination handling
Results
- created PR #862 refactoring the selection handling
- rough prototype for text edit activity refactoring is done
- smoke test pass (starting a session in Saros/I or Saros/E and editing shared text)
- started adjusting tests
- so far, all tests passed without having to adjust the setup (have not gotten to the important
GOTOInclusionTransformationTests, so this does not say much so far)
- created PR #868 to fix issue in split operation combination handling
Next Steps
- need to think about good sanity check for calculated selection positions
- selections are not handled by the Jupiter algorithm, meaning the base document can change without the selections being adjusted
- therefore, the conversion offset <-> text position might fail or the result might no longer be applicable to the base document
- such no longer valid selections should preferably be filtered out silently
- continue working on text edit activity migration to new positioning scheme
Problems
- refactoring of text edit activities is more complex than initially thought
- initial approach of using start, new end, and old end position can be used for text edit activities but not for operations
- operations are often transformed and shifted, meaning the end positions aren't useful
- resolved by moving to line delta and offset delta handling
Week 08 (CW 11)
currently working on milestone 3
Activities
- worked on prototype for refactoring the text edit handling to use the new positioning scheme
- migrated all existing tests for text activities, the Jupiter algorithm, operational transformations, and split operations
- all tests and STF test pass
- worked on refining the prototype to create an actual PR
- finished base version of refactoring of text edit activity
- migrated logic and tests
- still need to extend test suite to cover new cases added with migration
- improved selection refactoring PR #862
Results
- created test suite for API added in PR #862
- created PR #872 for text edit activity migration
- merged PR #842
- added missing base cases not covered by the previous test suite for SplitOperation and GOTOInclusionTransformation
- added more complex multi-line test cases for SplitOperation
- added more complex multi-line test cases for inclusion transformation
- debugged inclusion transformation
- finished work on PR #872 so that it is ready for review
Next Steps
- get PR #862 and PR #872 reviewed and merged
- start working on content normalization
Problems
Week 09 (CW 12)
currently working on milestone 3
Activities
- improved PR #872 according to review suggestions
- improved PR #862 according to review suggestions
- implemented fuzzer for inclusion transformation
- implemented content normalization for text edit activities
- implemented content normalization for the consistency watchdog checksum generation
- improved PR #877 according to review suggestions
- started working on preparing the migration to using reference points
- started working on removing partial sharing
- worked on removing access to partial sharing feature from UI
Results
- created PR #874 which adds an inclusion transformation fuzzer
- created PR #877 which adds content normalization for text edit activities
- created PR #878 which adds content normalization for the consistency watchdog checksum generation
- addressed review comments on existing PRs
- decided to stop working on content normalization for now
- current normalization is sufficient for an IDE cross-compatibility session
- remaining work rather offers a better user experiences and removes some weird behavior in edge cases
- there are more pressing issues that need to be addressed first
- → moved on to working on reference point refactoring
- created PR #880 removing access to the partial sharing feature from the Eclipse UI
Next Steps
- work on removing partial sharing
Problems
- partial sharing logic is not very well separated from the normal sharing logic, meaning removing it takes a lot of manual searching and adjusting of logic
Week 10 (CW 13)
currently working on milestone 3
Activities
- worked on removing partial sharing
- started thinking about design for reference point model
- discussed possible implementations for a new filesystem model
Results
- created PR #882 removing the partial sharing logic
- addressed review comments on existing PRs
- decided to postpone work on filesystem overhaul for now and instead work the new exclusion logic
Next Steps
- implement new exclusion logic
Problems
- how to deal with extending the scope of partial sharing
- issue if the extension of the scope leads to overlapping reference points, i.e. a reference point higher in the tree is chosen
- unclear what the actual use cases of Saros are/should be
- don't think using Saros to only share a partial tree with a participant not having the whole project is sensible
- task is more suited to screen sharing/remote desktop or the sharing done by VSCode (mirroring local IDE to other side)
- missing context of project will severely restrict IDE functionality (like looking up resources, library usages, language features, etc.)
- sharing whole project with user who initially has nothing only plausible without IDE integration with cross-IDE sharing
- not guaranteed that needed configuration files exist locally (see Saros; Eclipse files need to be generated) * not possible (to my knowledge) to in-place reload the correct project setup after adding the initial, general setup in Eclipse (i.e. always causes resource doubling, one contained in the initial, general project, the other contained in the correct projects loaded afterwards)
Week 11 (CW 14)
currently working on milestone 3
Activities
- worked on implementing new exclusion logic
- had discussion about new resource implementation
- merged existing PRs
Results
Next Steps
- design and implement the new resource handling
Problems
- resource - ID mapping is hard to integrate as there are multiple components that rely on its timeliness
- need to ensure that mapping is updated in time on file creations and is not updated too soon on file deletions
- encountered unhandled corner cases that lead to additional issues with new resource - ID mapping
- simultaneous creation of the same resource by different participants (additionally with different initial content)
- simultaneous move of the same resource (additionally to different locations)
Week 12 (CW 15)
currently working on milestone 3
Activities
- worked in design for new resource implementation
- fixed issue with Saros/I annotation logic
- prepared Saros/I release 0.3.0
Results
- created PR #900 fixing an issue with the Saros/I annotation logic
- created PR #901 preparing for the Saros/I release 0.3.0
Next Steps
- work on new resource implementation
Problems
- not as trivial as initially thought to define a simple resource model
Week 13 (CW 16)
currently working on milestone 3 (now actually)
Activities
- worked on cleaning up resource interface before beginning working on new resource implementation
- working through existing interfaces gave me good overview of current logic/implementation
- simplifying and unifying the interface and its implementation will make the introduction of a new resource system easier
- worked on improving charset handling
Results
- created PR #905 fixing an IDE cross-compatibility issue with the Saros/I file move logic
- created PR #906 removing the IResurce.move(...) method
- abstraction makes edge cases where resources are moved to a different project/module more difficult to handle
- as logic was never used in the core, it was not worth it to keep such an abstraction
- moving the logic to the IDE implementations offers the possibility of optimizing it for the specific IDE resource logic it is working with
- created PR #907 simplifying the resource interfaces IResource, IContainer, IFile, and IFolder
- created PR #908 simplifying the resource types defined in IResource
- merged PR #905, PR #906, PR #907, and PR #908
- created PR #913 adjusting the handling of received file activities to set the charset for created files
- created PR #914 adjusting Saros/E to always send the charset for file activities if necessary and requiring file activities to contain a charset if they contain binary content
- created PR #915 removing IContainer.getDefaultEncoding()
- created PR #916 removing IResource.adaptTo() and replacing its usage with simply casting the objects
- created PR #918 removing FolderMoveActivity as it was no longer being uses
Next Steps
- improve SPath abstraction/usage
Problems
Week 13 (CW 17)
currently working on milestone 3 (now actually)
Activities
- worked on replacing SPath in resource activities
- worked on completely removing the usage of SPath
- continued cleanup of resource interfaces
Results
- created PR #934 removing the usage of SPath from the resource activity implementations
- created PR #938 completely removing SPath
- created PR #943 removing IProject.findMember(IPath) as it was no longer being used
Next Steps
- continue cleanup of resource interfaces
- think about which abstraction level to use for the Eclipse implementation
Problems
Week 14 (CW 18)
currently working on milestone 3 (now actually)
Activities
Results
- created PR #950 removing IWorkspaceRoot as it was not being used in the core
- created PR #952 moving the remaining methods of IProject into IContainer
- this was done as a preparation for the move to reference points, which are basically all just containers in the eyes of Saros
- created PR #953 removing the methods IResource.getLocation() and getFullPath() to consolidate the path handling of resources to only use getProjectRelativePath()
- (worked on Saros/I caret handling)
Next Steps
- start with actual resource interface rework
Problems
Week 15 (CW 19)
currently working on milestone 3 (now actually)
Activities
- (finished work on Saros/I caret annotations)
Results
Next Steps
- continue planing new resource implementation and start reworking the IDE-specific implementations
Problems
Week 16 (CW 20)
currently working on milestone 3 (now actually)
Activities
- (continued working on release 0.3.0)
- worked on further cleanup for resource interfaces
- reworked javadoc for resource interfaces
- worked on migrating Saros/I to a reference point resource model
- created prototype reference point based resource implementation for Saros/E
Results
- created and merged PR #972 fixing an issue with the Java 11 build of Saros
- create PR #981 fixing the handling of empty selections
- created and merged PR #982 fixing a regression issue causing editors to open for newly created files during the project negotiation
- created PR #976 cleaning up the IWorkspace interface
- created PR #977 adding javadoc to the resource interfaces
- created PR #978 overwriting IProject methods where the functionality does not match the original parent interfaces defining the method and adds default implementations for methods with constant behavior
Next Steps
- continue working on Saros/I migration
- start working on Saros/E migration
Problems
- not that familiar with the Saros/E code, so the migration for Saros/E might take a lot longer
Week 17 (CW 21)
currently working on milestone 3 (now actually)
Activities
- (final steps in Saros/I release 0.3.0)
- worked on migrating Saros/I to a reference point resource model
Results
- merged PR #981 fixing the handling of empty selections
- created and merged PR #986 adjusting the version compatibility logic to ignore micro/patch version modifiers.
- created PR #997 introducing a reference point based resource implementation
- created PR #998 migrating the Saros/I core logic to use the new reference point resource system
- created PR #999 migrating the Saros/I UI to support the new reference point resource system
- created PR #1000 cleaning up after the migration to the new resource system
- created PR #1001 migrating the logic to handle local resource changes to support the new reference point based resource system
Next Steps
- get Saros/I migration PRs reviewed
- clean up references to project based resource system in core
- migrate Saros/E to reference point based resource system
Problems
Week 18 (CW 22)
currently working on milestone 3
Activities
- finisher initial work on Saros/I migration
- cleanup up Saros core
Results
- created and merged PR #1005 adjusting IContainer.members() to return a list instead of an array
- created PR #1008 removing references to the "reference point" concept from the Saros/I UI
- decided to keep this as an internal concept as it might confuse user
- speak of "shared root resources" in user world as they will probably already be familiar with this concept
- created PR #1012 cleaning up the Saros core
- removes references to old sharing system
- replaces mentions of "projects"
- renames IProject and related resource methods
- created PR #1019 removing AdditionalResourceData as it is no longer used
Next Steps
- work on saros/E migration
- review and merge Saros/I migration
Problems
Week 19 (CW 23)
currently working on milestone 3
Activities
- worked on Saros/E migration to reference point resource mode
- migrated inner classes
- started working on migrating the UI
Results
- created PR #1023 adding the new resource implementations
Next Steps
- migrate Saros/E UI
- migrate and fix STF tests
Problems
- UI adjustment is no as easy as thought as Eclipse tree viewer does not allow disabling elements
- workaround for now is simply dropping illegal user input
Week 20 (CW 24)
currently working on milestone 3
Activities
- worked on Saros/E UI migration
- migrated UI to choose resources on sender side
- fixed minor issues in previous migration steps
- migrated CollaborationUtils and its callers
Results
Next Steps
- migrate UI to accept resource negotiations
- migrate logic for Eclipse UI integrations (i.e. when to show what pop-up/dialog)
- migrate STF
- clean up Saros/E after migration
Problems
- UI is very purpose-build, meaning adjusting/modifying it is very complicated and requires large rewrites
- parts of UI logic are much more complicated than necessary (i.e. "overbuild") due to feature creep in the past
- additional logic not always integrated in a great way
- complicated and time-intensive to migrate
Week 21 (CW 25)
currently working on milestone 3
Activities
- worked on Saros/E UI migration
- finished initial work on UI migration
- migrated UI to accept incoming resource negotiations
- migrated Eclipse UI integration
- migrated remaining wording in UI
- migrated STF to work with new logic
- worked on debugging STF issues in docker without much success
Results
- merged PR #1026 allowing for Saros/E remove debugging using IntelliJ IDEA
Next Steps
Problems
Week 22 (CW 26)
currently working on milestone 3
Activities
- finished Saros/E migration
- cleaned up Saros/E code base
- worked on providing better local mapping suggestions for incoming resource negotiations
Results
- created PRs for the Saros/E migration to the reference-point-base resource model
- created PR #1032 migrating most internal classes of the Saros/E
- created PR #1033 migrating the filesystem handlers of Saros/E
- created PR #1034, PR #1036, and PR #1039 migrating the UI internals of Saros/E
- created PR #1035 migrating the wizard to select resources to create a resource negotiation with
- created PR #1037 migrating the wizard to select resources to represent the shared reference points when accepting a resource negotiation
- created PR #1038 and PR #1049 cleaning up Saros/E after the migration
- created PR #1040 adjusting the STF after the Saros/E migration
- created PR #1051 introducing logic to provide better mapping suggestions for incoming resource negotiations (especially for non-project/module directories) that works cross-IDE
Next Steps
- get open PRs reviewed and adjust for review comments
- start writing thesis paper
Problems
Week 23 (CW 27)
currently working on writing
Activities
- worked on writing the thesis
- worked on review comments for open PRs
Results
- created PR #1058 adding sanity check for nested reference points to core
Next Steps
Problems
Week 24 (CW 28)
currently working on writing
Activities
- worked on writing the thesis
- worked on review comments for open PRs
Results
Next Steps
Problems