GNOME Bugzilla – Bug 456240
Move all exchange related code to evolution-exchange
Last modified: 2009-10-27 20:07:10 UTC
Assuming there are no build-dependencies which would break this, I think it would be a good idea to move all of the Exchange support code to evolution-exchange. This would be the cleanest way of partially closing #342830.
Srini: assigning this to you, you are better placed to check with everyone related that this can happen. I'll happily do the work for this though.
I assume this is will have to be a post-GNOME 2.20 activity at this point?
I think we may have to discuss this to get to a conclusion. When I discussed with Varadhan, he told me that what is there was, moved from there. I dont know the reasons/decisions really. I totally forgot this, after guadec/current-2.12 work.
IIRC moving exchange server related code to evolution-data-server was done as part of removing the exchange button which would appear similar to the components "calendar", "mail" in evolution-1.5 time-frame etc. It was done with a plan to integrate evolution-exchange with EDS. The pending work which is still remaining is to move the provider code from evolution-exchange to EDS which IMHO is a more complex bit as I had understood from Varadhan. If this is done evolution-exchange would be removed and exchange would be running as part of EDS. At present the exchange operations plugin uses the EDS/servers/exchange library from EDS.
>>>>>>>>>>>> The pending work which is still remaining is to move the provider code from evolution-exchange to EDS which IMHO is a more complex bit as I had understood from Varadhan. Do you mean the Camel Provider ? If so, evolution-exchange module does not contain any calendar/address-book related things ? If not so, just ignore this.
Bumping version to a stable release.
Where do we stand on this now given the MAPI branch? Personally, I'd prefer all code that communicates with proprietary servers be cleanly split into separate extension packages: evolution-exchange evolution-groupwise evolution-zimbra ... etc ... Otherwise it feels like we're just adding bloat to Evolution-Data-Server.
Created attachment 137494 [details] [review] Patch for evolution-exchange This came up in last week's meeting so I thought I'd have a go at it. The patches here show changes made -AFTER- running: mv .../evolution-data-server/servers/exchange .../evolution-exchange/server The patch passes distcheck and -seems- to work for me, but someone needs to double-check that I ported all the Kerberos and LDAP configure gunk correctly. (I added a configure summary message to help verify that.)
Created attachment 137498 [details] [review] Patch for evolution-data-server This removes all exchange remnants from evolution-data-server. It too passes distcheck.
Note that this is intended as a quick hack to cleanse E-D-S of Exchange-related bits. I realize the evolution-exchange layout can be simplified further with the storage process and backend library now in the same package. I'll handle that separately: once these patches are in I will attempt to kill the evolution-exchange-storage process altogether for the benefit of the "kill-bonobo" branch.
Haven't read the meeting logs yet. But iirc we had put in a significant effort to move evolution-exchange to eds as part of moving exchange process into eds and also to have mail run as part of eds. It would be better if we make a decision on the future of evolution-exchange and make these changes. We would also need to think about having provider specific code in separate packages, we don have much resources to maintain all the packages. Say we write another provider for exchange 2007 using webservices in future. We might then need to have another evolution-webservices package. Prolly we can discuss over this more and move further.. I will read through the meeting logs and come back.
Bharath, it would good if you provide ur opinions as well..
Note these patches also fix a nasty circular library dependency between libexchange-storage and libedataserverui: -libexchange-storage lives in the "servers" directory, and depends on libedataserverui. - libedataserverui depends on libebook. - libebook depends on libcamel. - libcamel lives in the "camel" directory, and so does libcamelgroupwise. - libcamelgroupwise depends on libegroupwise. - libegroupwise lives in the "servers" directory.
I just had a discussion with varadhan to know the history behind the movement of the exchange code into eds and evolution while it was possible to have it in evolution-exchange itself. So it looks like certain cases where being over-looked while thinking about removing the evolution-exchange process. Iam ok with moving the code into evolution-exchange as this will give a choice for people to choose the lib-exchange storage rather than forcing everyone to install them. The same holds good for GroupWise too.
further to Chen's comment in comment#14, we can group, if wanted to, exchange related various providers webdav, MAPI and WebServices (future) to a single package and install three providers instead of having three-separate modules in git/package-list. Thus, evolution-exchange module in the git/svn will play as a parent tree for the three types of providers. Would be easy to maintain as a single tarball. Just a hacky $2 thought. :-)
FYI, I've added a patch to bug #590251 that builds on the one here. It converts the addressbook and calendar Bonobo servers in evolution-exchange to GTypeModules to work with the dbus-hybrid branch. Totally untested, meant to serve as a starting point.
*** Bug 364511 has been marked as a duplicate of this bug. ***
Created attachment 141733 [details] [review] partial evo patch (de-glade eex plugin) for evolution; here's a patch to de-glade plugins/exchange-operations in evo. I thought I will do this together with a movement to eex, but I realized few issues with it. a) e-util/e-dialog-widgets.h includes Glade. This can be changed by the struct _GladeXML; definition and including gtk/gtk.h there b) replacing gtk_tree_view_column_get_cell_renderers with gtk_cell_layout_get_cells (easy fix) c) calendar/gui/e-cal-popup.h includes e-cal-model.h > e-cell-date-edit-text.h > e-cell-text.h > libgnomecanvas/gnome-canvas.h which claims on an include of gtk/gtklayout.h, as we use GTK_DISABLE_SINGLE_INCLUDES not talking about added requirement of a gnome-canvas d) exchange-folder-permission.c is using calendar/gui/e-cal-menu.h which is not public header Here I stopped. I believe that at least the d) will be solved with a kill-bonobo branch merge to master, maybe a c) too. But because of the upcoming merge I will rather postpone it and would like to use this de-glade-ing patch as a start point. The patch is against master branch as of yesterday.
Created attachment 141734 [details] eex patch I started with for evolution-exchange; I'm not sure if it'll be usable at all, but just have it here as a possible start point.
(In reply to comment #18) > a) e-util/e-dialog-widgets.h includes Glade. This can be changed by the > struct _GladeXML; definition and including gtk/gtk.h there You can blow away that include, along with e_dialog_xml_widget_hook_value(). It's no longer used. > Here I stopped. I believe that at least the d) will be solved with a > kill-bonobo branch merge to master, maybe a c) too. But because of the upcoming > merge I will rather postpone it and would like to use this de-glade-ing patch > as a start point. The patch is against master branch as of yesterday. EMenu and EPopup are officially dead, but I have not yet converted the Exchange plugins over to EPluginUI. We'll have to do that post-merge. Patch is a good start though.
Created commit 17ccb42 in evo master (2.29.1+) (for comment #18) Note it was committed in one commit, together with bug #593609 comment #4.
Created commit cdd5f2c in evo master (2.29.1+) Created commit d0236a9 in eex master (2.29.1+) The exchange plugin is moved to exchange package now.
Matt, will you take care of the eds part? I guess it's slightly outdated. When it'll be done, then we can continue with bug #591953.
Will do. Give me a few days, as I'm on travel starting tomorrow.
It's done. I'll try to respond quickly to any regressions I caused. http://git.gnome.org/cgit/evolution-data-server/commit/?id=418fe0489c7dcccb5e98efe28f9c5b3071e18e4b http://git.gnome.org/cgit/evolution-exchange/commit/?id=4b2c20de87bc899f1ade4bb098e5d06fcb9b425f Closing as FIXED.
I created commit 862c71e in eex master, to fix some build/runtime issues. I noticed some strange regressions: a) exchange prints again its empty lines like crazy when accessing it. It didn't do that before move of eds code to eex, which makes me wonder whether you used the old patch or moved recent code. b) (Also seems you used the old patch, because) .eplug variables replace code had been broken in your commit. c) I cannot open my exchange calendar, it claims for Permission denied, but I bet I could open that calendar before the change. d) My fault I included .eplug and .error files in /eplugin dir in sources, these are generated, thus shouldn't be part of source. I fixed that as part of the above commit. e) I also changed some libraries for linking, as libevolution-exchange-shared.la is supposed to be linked to camel/calendar/addressbook modules.
Created attachment 145109 [details] changes these are changes in eex, when I copy old eds files over those in actual eex master (at commit 862c71e). Most changes seem fine, except those at the beginning, as the awk "code" changes spacing as well. I do not know it much, neither what it does or doesn't, but my be-on-the-safe-side part is telling me to not add spaces there. Please check briefly also the rest of changes in this file. Knowing this, I've no idea why it didn't print spaces before the code move, but it does know. I do not expect it being because of awk changes, or...
*** Bug 561407 has been marked as a duplicate of this bug. ***