openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ankush Mishra <>
Subject Re: GSoC: Discussion on Libraries to use for CalDAV
Date Thu, 28 Apr 2016 07:35:00 GMT
Alright, makes sense.

Should I leave their Apache Slide issue temporarily and if possible later
check up on their jackrabbit-webdav dependencies, and make changes in a
fork for it?
Or just leave it as it is and add necessary changes as and when needed?

I'll have to look into their codebase this week, to get a hang of it, in
any case.

On 28 Apr 2016 09:34, "Maxim Solodovnik" <> wrote:

> If I were you I would use :)
> You always can fork it fix something and propose PR to the original repo
> :) I would update libraries they are depend on :)
> In case their community is not active at all I can publish necessary
> artifacts into our own repo:
> On Thu, Apr 28, 2016 at 6:56 AM, Ankush Mishra <>
> wrote:
>> Looks like I forgot to CC, again. Would love to hear what you all think
>> on this.
>> Ankush
>> ---------- Forwarded message ----------
>> From: "Ankush Mishra" <>
>> Date: 27 Apr 2016 19:34
>> Subject: GSoC: Discussion on Libraries to use for CalDAV
>> To: "dev" <>
>> Cc:
>> Here's the current list of CalDAV library implementations in JAVA:
>>  - iCal4j (which is used in the project already for handling ics):
>>    This is already used to send out event invites through email. Just
>> that this might still be used for handling CalDAV as the calendar data is
>> still made up of iCal.
>>     There exists an iCal4j-connector which from their page, also,
>> implements the CalDAV using jackrabbit-webdav library. But it's development
>> seems to have stopped since 2013.
>>  - CalDAV4j ( ):
>>    From their Project Page:
>>    CalDAV4j is a protocol library that extends the Slide project's WebDAV
>> client library (which itself is an extension of the Apache's HttpClient
>> library) to allow high level manipulation of CalDAV calendar collections as
>> well as lower level CalDAV protocol interactions. This project uses iCal4j
>> for iCalendar processing.
>>    This project is promising and their library is stable to use. But from
>> their googlecode commits it was last commited on Nov 2013, though since
>> moving to GitHub, it still hasn't had much happen.
>>    One thing I have noticed it's still missing the CalDAV ACL's, things
>> like "PRINCIPAL" query haven't been implemented. I'm also not sure of it's
>> status of development or it's integration to the JackRabbit sources, but
>> from digging up it's history I notice that the Open Source Applications
>> Foundation (OSAF) is now defunct, and thus, it might seem like the project
>> is at a halt. There also seem to be issues with jackrabbit-webdav
>> integeration, it still seems to be using Apache Slide as the WebDAV
>> library, atleast in the master branches, though there is a branch on the
>> Google Code for caldav4j-webdav using the jackrabbit-webdav library(
>>  - JackRabbit-WebDAV (
>> :
>>    Taken from their project page:
>>    This is the WebDAV Library component of the Apache Jackrabbit project.
>> This component provides interfaces and common utility classes used for
>> building a WebDAV server or client.
>>    It supports DAV 1, 2, DeltaV, Ordering, Access Control, Search, Bind.
>> In the end both CalDAV4j and Jackrabbit-webdav, can be used. It'd be
>> preferrable to use CalDAV4j, which directly implements CalDAV protocol but
>> extends Apache Slide WebDAV protocol library. The main problem with
>> caldav4j is that Apache abandoned Slide in 2007 and therefore it is based
>> on a deprecated library (now Apache advises to consider Jackrabbit project
>> instead). And Jackrabbit-webdav implements only WebDAV specific code. Some
>> operations will be very familiar if you already have experience with HTTP
>> services (GET, PUT and DELETE), but many are added too (MKCOL, MKCALENDAR).
>> Thus comes the dilemma of which library to use, perhaps at some part even
>> the CalDAV4j, could fail, and it would be easier to use jackrabbit-webdav
>> at places to implement parts which don't already exist.
>> In the end, I'm still not certain of which library to use.
>> Ankush
> --
> Maxim aka solomax

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message