Alright that makes sense. I think ioggstream, the Project Maintainer would be fine with merging, as long as we get a version after migration which works with very few bugs.
I like the steps you've mentioned and thus should hopefully get working on that. This plan is sound and I hope to emulate it. Much Thanks Ankush Mishra On 9 May 2016 13:15, "[email protected]" <[email protected]> wrote: > 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 > > Thanks, > Sebastian > > > 2016-05-09 12:11 GMT+12:00 Ankush Mishra <[email protected]>: > > > 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 > https://twitter.com/#!/dead_lock > [email protected] >
