This page is about Nuxeo Drive 2. For versions 1.x see the page Nuxeo Drive 1.x Dev Documentation.
After Nuxeo Drive has been installed on the server, users have a Nuxeo Drive tab on their Home.
The development workflow is described on that Wiki.
Nuxeo Drive is written in Python and make heavily use of the Qt framework. This allowes to easily create a multi-platform desktop application using the same code base.
We tend to follow the PEP8, that's all.
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 install
Note: 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.
- 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.
Handle the basic commandline arguments, create the Manager, and depending on the argument create a ConsoleApplication or Application.
Handle all the generic behavior of Nuxeo Drive: auto-updates, bind of an engine, declaration of different engine types, tracker.
Handle one server synchronization, can be extend to customize the behavior, it creates all the synchronization structure: QueueManager, LocalWatcher, RemoteWatcher, DAO.
Abstraction for accessing the SQLite database, each Engine has its own DAO and so database
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
Handle the remote scan for the first synchronization and then the incremental polling from the server
Handle the different types of Processor to process any remote or local modification
Specialized thread in uploading document
Specialized thread in create remote folder
Specialized thread in download document
Specialized thread in create local folder
If the queue is big, some additional Processor will be launch by the QueueManager to either download or upload document
Handle the auto-update polling and the update download process
Use for Analytics, anonymous report of usage
Console behavior implementation
OperatingSystem GUI handles the creation of windows, systray and message
Load labels translation and offer the translation service as static method
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" target="_blank" rel="noopener