Yeah, so unless Microsoft is going to pay to provide all contributors with an SDK, we can consider it EOL.
It should be fine to test against OpenJDK6 though, apart from some crypto differences it should be the same.
Erik van Paassen
Open JDK6 is better than nothing, even if it's not as good as using the Oracle JDK. It's disappointing that Travis CI doesn't support Oracle JDK6. EOL or not, Java 6 was around for over four and a half years before Java 7 was released. You couldn't pry it out of many enterprise organizations with a crowbar.
Does ews-java-api supports OAuth ?
No. EWS does not support OAuth (well, actually it sort of does a little bit of OAuth, but it is not too useful, since you need full mailbox permissions)
EWS service in Office 365 supports OAuth providing the ability for an app to access your mailbox with seeing your password. However, it doesn't support fine grained consents so like the OData API which supports consents like read mail, send mail, calendar and contacts. Ews-java-api doesn't support OAUTH though.
I meant without seeing.
since there is no 'user consent' scenario for EWS, even with O365, I think it's fairly useless
if an admin needs to give full access, he can create a service account as well
I think OAuth gives benefits like: 1. app doesn’t see password, 2. constrained access, 3. ability to revoke. Would EWS OAuth give you 1 and 3, but not 2?
It would be use for developers of services / applications requiring such access rather than admin.
EWS with application impersonation also gives you 1, and I'm not sure EWS OAuth gives you 3. on a per user basis
So essentially using OAuth with EWS instead of app impersonation is just swapping the (app specific) username/password for an OAuth token
anbyody got experience publising to sonatype?
the ticket is ok, so I guess we can start publishing snapshots any day now?
afaik it's just a matter of configuring the deploy plugin in the pom.xml
but yesterday we discovered HEAD is currently borked with some firewalling configurations (e.g., TMG)
Note that EWS does support OAuth in Office 365, for both code and client-credential flow. The only difference to the Rest APIs is the permissions. EWS only supports "full access to mailbox" while Rest APIs do only support the granular permissions specific to a class of resources (Calendar, Mail, Contact). We recently updated the permission strings in the Application registration portal to better signal what is available for EWS. From a OAuth protocol point of view there is no difference. Note that maybe you had some issues in the preview phase where we marked the "full access to mailbox" permission as "admin only", meaning they required an admin to consent. With GA we removed this restriction. All permissions are now consent-able by an end-user. More here: https://msdn.microsoft.com/en-us/library/office/dn903761(v=exchg.150).aspx
I agree on the "push-pr-merge" when we have a stable release to rely on, but perhaps we should have a bit more restricted push-policy until then?
I would also suggest in autodeploying snapshots to the maven snapshot repo. The following needs to be handled when we try to do that:
username and password should be encrypted (even if this sounds like an easy step for travis maybe it could be usefull to create another jira-account (@ossrh) which only has privileges to deploy to the snapshot repo)
deployment should only be done by one of the 3 builds and only if all verification is successful
KISS (keep it simple and stupid)
@pathikrit the mentioned python-script looks a little stuffed. Maybe there is a more lightweight alternative
@ahaarrestad dont think push-policy should be restricted since a snapshot release will always be a snapshot and not a stable one
Hi... just getting started here.
Wondering what happened to 1.3? Was it ever released (ie: maven released) ? or is the 2.0-snapshot the only available version in sonatype.org ?
If the answer is yes... do you know when 2.0 will be released?
Would be nice to have a stable/released version to base my app. on.
We are currently planing the 2.0 release milestone. Therefore everybody is invited to declare issues that need to be fixed before the deployment is done. Maybe for not breaking packages again a restructuring of the classes in packages and subpage would be useful. This could be handled like it is in the ews-managed-api.
while thinking on that package restructuring I would suggest in not doing this with the 2.0 release since this would force every user to update their imports which could be dangerous if people just change maven dependency from snapshot to stable. Maybe we can include these restructuring into another major release. I think this would make live easier.
Can anybody tell me if the old timezone setting problem from ews 1.2 has been fixed already?