After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 456240 - Move all exchange related code to evolution-exchange
Move all exchange related code to evolution-exchange
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: general
1.12.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: Srinivasa Ragavan
Evolution QA team
: 364511 561407 (view as bug list)
Depends on:
Blocks: 342830
 
 
Reported: 2007-07-12 13:40 UTC by Ross Burton
Modified: 2009-10-27 20:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch for evolution-exchange (74.73 KB, patch)
2009-06-28 14:11 UTC, Matthew Barnes
none Details | Review
Patch for evolution-data-server (3.76 KB, patch)
2009-06-28 14:30 UTC, Matthew Barnes
none Details | Review
partial evo patch (de-glade eex plugin) (72.08 KB, patch)
2009-08-26 10:39 UTC, Milan Crha
committed Details | Review
eex patch I started with (349.58 KB, text/plain)
2009-08-26 11:05 UTC, Milan Crha
  Details
changes (13.02 KB, text/plain)
2009-10-09 09:16 UTC, Milan Crha
  Details

Description Ross Burton 2007-07-12 13:40:37 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.
Comment 1 Ross Burton 2007-07-12 13:54:33 UTC
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.
Comment 2 Matthew Barnes 2007-08-12 22:09:53 UTC
I assume this is will have to be a post-GNOME 2.20 activity at this point?
Comment 3 Srinivasa Ragavan 2007-08-13 04:21:13 UTC
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.
Comment 4 Chenthill P 2007-08-14 03:47:26 UTC
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.
Comment 5 Sankar P 2007-08-14 05:20:40 UTC
>>>>>>>>>>>> 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.

Comment 6 Matthew Barnes 2008-03-11 01:00:54 UTC
Bumping version to a stable release.
Comment 7 Matthew Barnes 2008-03-16 20:01:20 UTC
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.
Comment 8 Matthew Barnes 2009-06-28 14:11:20 UTC
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.)
Comment 9 Matthew Barnes 2009-06-28 14:30:23 UTC
Created attachment 137498 [details] [review]
Patch for evolution-data-server

This removes all exchange remnants from evolution-data-server.  It too passes distcheck.
Comment 10 Matthew Barnes 2009-06-28 14:47:48 UTC
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.
Comment 11 Chenthill P 2009-06-28 16:56:22 UTC
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.
Comment 12 Chenthill P 2009-06-28 16:58:23 UTC
Bharath, it would good if you provide ur opinions as well..
Comment 13 Matthew Barnes 2009-06-29 02:18:32 UTC
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.
Comment 14 Chenthill P 2009-06-30 05:53:44 UTC
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.
Comment 15 Veerapuram Varadhan 2009-06-30 09:14:15 UTC
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. :-)
Comment 16 Matthew Barnes 2009-07-30 17:20:09 UTC
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.
Comment 17 Matthew Barnes 2009-08-25 16:06:13 UTC
*** Bug 364511 has been marked as a duplicate of this bug. ***
Comment 18 Milan Crha 2009-08-26 10:39:37 UTC
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.
Comment 19 Milan Crha 2009-08-26 11:05:17 UTC
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.
Comment 20 Matthew Barnes 2009-08-26 11:53:05 UTC
(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.
Comment 21 Milan Crha 2009-09-25 08:30:23 UTC
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.
Comment 22 Milan Crha 2009-10-02 13:10:56 UTC
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.
Comment 23 Milan Crha 2009-10-02 13:13:32 UTC
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.
Comment 24 Matthew Barnes 2009-10-02 13:21:43 UTC
Will do.  Give me a few days, as I'm on travel starting tomorrow.
Comment 26 Milan Crha 2009-10-09 09:03:32 UTC
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.
Comment 27 Milan Crha 2009-10-09 09:16:23 UTC
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...
Comment 28 Milan Crha 2009-10-27 20:07:10 UTC
*** Bug 561407 has been marked as a duplicate of this bug. ***