The development workflow is described on that Wiki.
Nuxeo Drive is written in Python and make heavily use of the Qt framework. This allows to easily create a multi-platform desktop application using the same code base.
We tend to follow the PEP8, that's all.
To help with this requirement, you can automate checks and formatting using pre-commit: it will call predefined hooks and black for you to ensure there is no regression and to keep the code clean.
For core developers, the whole mechanism is installed with the developer environment. But if you are a contributor, you can easily use it:
python -m pip install pre-commit
pre-commit installNote: on Windows you will need to have Git installed.
This guide is for developers willing to work on the Nuxeo Drive codebase itself.
Note that many behaviors of Nuxeo Drive can be customized without actually changing the code of Nuxeo Drive but by contributing to the server side extension points instead.
The projects comes into two parts: the addon deployed on the Nuxeo server, written in Java, and the client written in Python.
Nuxeo Drive client is a Python desktop application that looks for changes on the local machine filesystem in a specific folder and on a remote workspace on the Nuxeo server using the Content Automation HTTP API and propagates those changes one way or the other.
To build the nuxeo-drive addon see the related nuxeo GitHub repository.
To build the Marketplace package see the related marketplace-drive GitHub repository.
See docs/deployment.md.
- The Dependabot will automatically check for updates and opend a PR if needed.
⚠️ SECURITY: before upgrading a package, ensure its source code and its updated dependencies are safe to distribute.
CommandLine
Handle the basic commandline arguments, create the Manager, and depending on the argument create a ConsoleApplication or Application.
Manager
Handle all the generic behavior of Nuxeo Drive: auto-updates, bind of an engine, declaration of different engine types, tracker.
Engine
Handle one server synchronization, can be extend to customize the behavior, it creates all the synchronization structure: QueueManager, LocalWatcher, RemoteWatcher, DAO.
DAO
Abstraction for accessing the SQLite database, each Engine has its own DAO and so database
LocalWatcher
Handle the local scan on startup and then the FS events, updating the States stored in DAO, and if needed queueing the State to be processed
RemoteWatcher
Handle the remote scan for the first synchronization and then the incremental polling from the server
QueueManager
Handle the different types of Processor to process any remote or local modification
RemoteFileProcessor
Specialized thread in uploading document
RemoteFolderProcessor
Specialized thread in create remote folder
LocalFileProcessor
Specialized thread in download document
LocalFolderProcessor
Specialized thread in create local folder
AdditionalProcessor
If the queue is big, some additional Processor will be launch by the QueueManager to either download or upload document
AppUpdater
Handle the auto-update polling and the update download process
Tracker
Use for Analytics, anonymous report of usage
ConsoleApplication
Console behavior implementation
Application
OperatingSystem GUI handles the creation of windows, systray and message
Translator
Load labels translation and offer the translation service as static method
WebDialog
Base of all Nuxeo Drive window, it is basically a WebKit view with a Drive JavaScript object mapped by the JavaScript API
QT is heavily used in the new client. Here is a diagram of the signals/slots connections:
RemoteWatcher logic schemas: https://www.lucidchart.com/documents/view/3081771a-786b-486e-bfaa-ee7ae77a3807
LocalWatcher logic schemas: https://www.lucidchart.com/documents/view/21ec315b-3917-44aa-b9bd-5ccedfcfb02f
GUI
Here is the diagram of the GUI section
DirectEdit
Here is the diagram of the DirectEdit section
DirectTransfer
Here is the diagram of the DirectTransfer section
