EWS Community Project

[Kooki]

HI @all,

as written in some other threads/issues EWS, it's SOEAP API and EWS SKD (Java, .Net) will no longer receive any updates (see HERE). @MIchaelMainer suggested here to create a community fork and link this fork on official readme.md

So here we go...There are some people who have 'active' forks. SO lets collect information, ideas and some good vibes here and start this. I'll link all people here to get some attention. Hopefully we'll get this thing done.

Thanks Jan/ @OS-JaR

FYI/CC: @yinaa, @serious6 , @CodeDog369 , @hasselbach , @MIchaelMainer , @davidmoten , @kentongray

[henrywright88404]

Hi @Kooki ,

I am Keen to be part of a team that manages and maintains an unofficial 'official' fork.

I say 'part of a team' as I haven't maintained an API before so would like to learn from someone.

[pkropachev]

From my point of view the following several things that should be done:

• Migrate to Java 11;
• Support new versions of Exchange; The current list of versions from Services.wsdl (Office 365):

<!--  Enumeration of Exchange Server versions  -->
<xs:simpleType name="ExchangeVersionType">
    <xs:restriction base="xs:string">
        <xs:enumeration value="Exchange2007"/>
        <xs:enumeration value="Exchange2007_SP1"/>
        <xs:enumeration value="Exchange2009"/>
        <xs:enumeration value="Exchange2010"/>
        <xs:enumeration value="Exchange2010_SP1"/>
        <xs:enumeration value="Exchange2010_SP2"/>
        <xs:enumeration value="Exchange2012"/>
        <xs:enumeration value="Exchange2013"/>
        <xs:enumeration value="Exchange2013_SP1"/>
        <xs:enumeration value="Exchange2015"/>
        <xs:enumeration value="Exchange2016"/>
        <xs:enumeration value="V2015_10_05"/>
        <xs:enumeration value="V2016_01_06"/>
        <xs:enumeration value="V2016_04_13"/>
        <xs:enumeration value="V2016_07_13"/>
        <xs:enumeration value="V2016_10_10"/>
        <xs:enumeration value="V2017_01_07"/>
        <xs:enumeration value="V2017_04_14"/>
        <xs:enumeration value="V2017_07_11"/>
        <xs:enumeration value="V2017_10_09"/>
        <xs:enumeration value="V2018_01_08"/>
    </xs:restriction>
</xs:simpleType>

• Solve the current problems with authentication and support OAuth2 (support Basic Authentication access for EWS ending October 13, 2020).

[navpil]

Hi @Kooki ,

Sorry for the silly question - but what should the "official community fork" look like? Is it just something we agree upon here? Do you know of any fork which we can now call to be a "official community fork"?

I'm asking because I'm using EWS quite a lot and sometimes I fix some issues and add functionality available through the raw SOAP, but not included into the managed API. I have also migrated to Java 11. This was all done internally for my client, but I would like to contribute these changes into some community fork and in turn get the more up-to-date EWS API.

Can you suggest anything?

[philipwhiuk]

I propose we create a new ews-unofficial-api / ews-community-api GitHub organisation and add people to that.

To start with we could have a fairly rigorous GitHub code review process. We'll need a major version release that breaks absolutely no APIs - signifying the ownership change, to allow everyone to migrate off to the community API.

I'd start with making a major release that just changes the ownership, then start looking at community forks for contributions to downstream.

Then we can proceed as normal - with breaking changes being another major version - following semver :)

[philipwhiuk]

If I don't get any feedback by November, I'll probably just create the org and start this process..

[navpil]

@philipwhiuk I think your idea is good. Actually I wanted to do this the same day you mentioned that, but then I stopped because I was wondering about the details. For instance - the version change. Shouldn't we change the groupId for the artifact instead? If we leave it at com.microsoft.ews-java-api it might be misleading. For instance what if (I doubt that but still) Microsoft decides to continue development of this API. If Microsoft officially transferred the code to community, there would be no problem. But this will be only the unofficial fork. What do you think about it?

[henrywright88404]

@philipwhiuk @navpil

A community fork was set up here

To date, nothing other than having a fork set up has been done. maybe this discussion is better had there to get the ball rolling?

[OS-JaR]

Hi @henrywright88404 ,

thanks for pointing out our existing community fork.

@navpil , @philipwhiuk we already have a community project.you also should be invited right now. As @pkropachev already said, we should start to collect some points we've to do. Either as GitHub issus or with help of an organisation tool (trello or smth else). Maybe we also want to start an discussion group (discord/slack?).

Thanks Jan

[pkropachev]

We can continue if someone needs it. It makes sense to have some discussion group.

[shymega]

I think setting up a real-time chat platform would be beneficial.

Currently writing a Java application, like Davmail, but designed to run as a daemon - plus with backends, so it can support MS Graph, and EWS for those who need it.

I haven't been able to get this repo's SDK working in my initial tests but would be keen to help out.

Davmail isn't supporting SMTP as a shared mailbox at this time, but I'm finding the codebase a bit heavy, and I had a different approach for the internals on my design.

I am considering making this a plugin for Apache James.