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.
We tend to follow the PEP8, that's all.
For core developers, the whole mecanism is installed with the developer environment. But if you are a contributor, you can easily use it:
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 daemon 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-drive-server GitHub repository.
To build the Marketplace package see the related marketplace-drive GitHub repository.
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 differents 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