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]
