Hi Nicolas
Thanks for taking a look at eDrive.
I will take a look at the build issue you are having but it's working for me so it might take a bit more investigation. We do normally run these maven goals from within Eclipse but I did just try it on the command like and it built and installed OK. I'll let you know what I find. In the mean time, you could just install the eSync jar file to your local maven repo.
Basically we decided to take a completely different approach to Native Client development. The reason I designed the socket based command server and multicast event server was so that ANYBODY could write a light weight native UI for Windows Explorer, Mac OSX Finder the various versions of Linux File Managers, Swing and Web UI clients without having to include any eSync or eDrive libraries or API's in their projects. They simply connect to the command server socket and issue simple commands while listening and reacting to events from the multicast server. This also means we do not have to get involved in the language translations but we would hope that popular UI's will be translated by the Open Source community. In the mean time we will continue developing our own set of Branded UI's.
With this approach the Open Source community can build a good choice of light weight UI's while other users may choose to integrate directly with other solutions. One such client could be a Round Robin DB application that simply listens for eDrive Multicast events and aggregates the results then generates real time performance and monitoring graphs.
We wrote eDrive because we could not meet our use cases with the existing Alfresco Desktop Sync product and some of our users wanted a more DrobBox like experience, this is why we are currently writing our own branded light weight native Windows Explorer client ourselves.
We have some pretty good stuff planed for future releases of eDrive and not just in the sync space. This release was designed to get some feedback, the next release will add some Enterprise features such as SSL and Proxy support as well as a pluggable authentication module based on JAAS and a user configurable mime type mapping where users will be able to setup mappings for document mime types to custom Repository types other than just the current default cmis:document type. This will allow eSync to create new Repository entries using base types defined by users falling back to the cmis:document should the mapped type not exist in the Repository or is not a suitable base type for the content.
Anyway I digress, I have no issues with EOSSOnline Limited Collaborating with you guys on a generic Open Source solution that the community can get behind. We as a company have only one condition and that is joint IP ownership (where we can provide our customers with a different license) along with an Apache 2.0 licensed version. If you guys are OK with this then we can talk more.
Regards
Steve