openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject Re: GSoC 2016: Status and some concerns regarding caldav4j
Date Mon, 09 May 2016 07:44:44 GMT
Well, the goal should be more that we bring the caldav4j changes you do in
a state where it is worth considering by the main developers to merge to
the master branch.

We cannot really integrate a library from your branch. We can integrate it
temporarily, for the duration of your GSoC project.
But once we want to really merge it into the main OpenMeetings source code
and release it the problem starts:
 - We need a Maven artefact of your code, not just a compiled library
 - We need a release version of your code (No Snapshot version dependencies
are allowed for a release)

I am aware that there are tricks to get around those rules (like custom
Maven repositories et cetera). However this can only be an exception, not
the standard rule that we just do with everything.
Also this kind of fragmented development makes it very hard for 3rd parties
to participate in the project since we make very complicated to understand
the dependencies.

So the end goal has to be that your code becomes part of the master branch
of caldav4j and that there is a release of that library that contains your
patches (or a merged version of it). However let's tackle it one by one. So
in order of priority:
1) Fix what you have to fix and make it work for OpenMeetings
2) Finish the rest of your GSoC requirements successful
3) If you have the time bring the caldav4j stuff in a state where we can
propose a patch to their main branch


2016-05-09 12:11 GMT+12:00 Ankush Mishra <>:

> I fixed the building the code for the project, which was caused due to a
> couple of bugs in the code, albeit small ones.
> No problems with just the partial migration. In fact the library works out
> of box, without any migration. Having tested it myself. I'll probably do a
> slow migration as I see fit. Plus, since development is sort of halted, it
> won't be a issue, maintaining compatibility with the master and my fork.
> Much thanks
> Ankush Mishra

Sebastian Wagner!/dead_lock

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