- Home
- About Saros
- Installation & Set-Up
- Support
- Develop on Saros
- Check-Out and First Steps
- Ongoing Work
- Guidelines
- Tools
- Processes
- Mailinglists
- Bug Tracker
- Saros@Sourceforge
- Google Summer of Code
- FAQ in daily practice
- Update local code to master
- Revert local changes
- Upload a new patch set
- Building in Gerrit failed!
- Get & run someones change
- Change? Patch set? Submit?
- Check Gerrit permissions
- Delete local branch
- Duplicate Location Error
- Review a change
- Run STF tests locally
- STF tests fail
- Set up STF tests
- Write STF tests
- Git use-cases
- Technical Documentation
- Research
- Contact
Overview
Techniques in Saros
Basically the following three techniques are used to develop Saros:
-
Java as programming language
-
XMPP as communication layer
-
Eclipse as target development environment to enhance
Architecture
Since Saros is based on XMPP, it uses a server based architecture. Communication between clients is done by XMPP messages which are send over XMPP servers. Exchanging client actions (modifications, selection, project file operations,...) is done by wrapping activity descriptions in XMPP messages and sending them to other clients. An exception is the file transfer. Due to performance reasons it uses a peer to peer transfer. If this direct connection fails, Saros uses a fallback to file transfer over XMPP servers.
Software Architecture
Saros uses a layer architecture and consists of eight major modules as you can see in the image below. The Whiteboard is an additional project which expands the functionality of the Saros plug-in.
Internal Dependency Management
We use the PicoContainer library to manage our component instances using the Dependency Injection (DI) design pattern.
During Runtime
We are using two different DI containers (or "contexts"): The Plugin Context is started when the Saros IDE plugin starts, and exists as long as the Saros instance is running. A second container is created whenever a Saros session is started, and it is teared down when the session ends. Components from the Session Context can access components from the Plugin Context, but not the other way around.
At Compile Time
Since Saros comes in different variants (a plug-in for Eclipse, one for IntelliJ IDEA, and also as a stand-alone server), the components used at run-time are distributed between the common Core and the specific IDE plugin code.
The following schema shows a typical situation for the Eclipse plugin (continuing the example above).
The example illustrates the following aspects:
- IA is an Interface defined in the Core, and it is implemented by component A in the IDE plugin. Implementing IA is optional from the perspective of the IDE plugin, but it might be helpful (the AbstractContextLifecycle is a real-world example from the Saros code).
- IB is defined in the Core, and needs to be provided with an implementation by the IDE plugin as Core-component E needs it.
- IC is IDE-dependent.
- ID and IE both define Core components, of which D can be readily used, while E needs the IDE plugin to provide an IB implementation.
- Note: Interfaces ID, IC, and IE could be removed to let components A and B depend directly on D, C, and E, respectively (see image below). Many components in Saros don't have a separate Java interface for this reason.
Putting together the contexts: Creating the Mapping
The actual mapping from interfaces to concrete components is what is put into the DI container. In the case of Saros, there are two dimensions that need to be considered: First, there are two contexts (long-lived Plugin Context and short-lived Session Context); second, there are general Core components and specific IDE components. In Saros, we separate these concerns by n times m "context factories" (n=2 for 2 containers, m=4 for Core, Eclipse, IntelliJ and Server). The above example would be realized by the following four context factories:
