[cross-project-issues-dev] OAuth 2.0 Eclipse Services
Greetings cross-projects, for the error reporting I’d like to give committers/reporters the ability to store personal preferences and get access to the errors they sent in the past, current status of these problems etc. For that I need to authenticate users by email address. One (half-baked) idea is to allow users to register using some OAuth provider like Google, Github or - if supported - eclipse.org http://eclipse.org/. My question is, does any eclipse project have OAuth working in their code base (plugin or server)? Which libraries do you use and what else should we be aware of? Thanks for pointers, Marcel___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Error reporter and third-party code
Konstantin, I dug a bit deeper into Sapphire error reports. My conclusion: Adding more open source namespaces wont help much in your (and Nebula’s) case. Most reports mentioning Sapphire are from the namespaces oracle.eclipse.tools.* and com.liferay.* Some reports show that Sapphire clients even do not follow the bundle name to package name conventions. Neither oracle.eclipse.* nor com.liferay.* seem to be open source namespaces. Regarding your popup question: I sense that asking a user for permission whenever a non-eclipse namespace was discovered in the trace will quickly be very annoying. The next thing to consider: We only send errors that are logged by eclipse.org http://eclipse.org/ / apache.org http://apache.org/ plugins. However, it's likely that com.liferay will log errors that reference Sapphire classes. Following your previous arguments, you would be interested in those as well. Here we get into trouble. If we do so, we would need to send every error report that mentions at least one Eclipse class to eclipse.org http://eclipse.org/. if we do so, users will notice dozens of „an error was logged“ popup appears per day (b/c some 3rd party plugins causes trouble) and will conclude that Eclipse is extremely buggy. I’m not sure I wanna go down this road. At some point we need to draw a line between error that are caused by third-party plugins (like Liferay or Oracle) and those caused by Eclipse plugins. I agree to your previous statement that if we can't make sense of error reports containing third-party traces, we should not collect them. This will certainly lead to a better user experience and is something we should definitely change for SR1. I see that this does not solve your issue with Sapphire clients but in this regard I’m more with Gunnar. I think those clients (which currently make ~28% of the error reports) should actually sign-up and subscribe to their error reports - or set up their own error collection to review and fix their issues themselves. But if we collect them for them, it must be clear to the users that these errors are caused by Liferay, Oracle, Findbugs or whatever third-party plugin. Eclipse should not make the impression of being buggy if third party plugins are behaving badly. Marcel Am 23.07.2015 um 19:23 schrieb Konstantin Komissarchik konstantin.komissarc...@oracle.com: A big +1 -Original Message- From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Max Rydahl Andersen Sent: Thursday, July 23, 2015 5:12 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] Error reporter and third-party code On 22 Jul 2015, at 20:37, Marcel Bruch wrote: Konstantin, I assume you understand that user may find stacktraces to contain potentially sensitive data (if not - let’s assume it hypothetically), which options would you propose? I'll repeat what I've suggested in the past: add more to the list of OSS packages, i.e. add org.jboss.*, *.redhat.* and org.spring.* and possible more from the top 10 OSS plugins on marketplace. So at least the OSS collaborators can be contacted and we can help improve ;) /max http://about.me/maxandersen ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Codetrails GmbH The knowledge transfer company Robert-Bosch-Str. 7, 64293 Darmstadt Phone: +49-6151-276-7092 Mobile: +49-179-131-7721 http://www.codetrails.com/ Managing Director: Dr. Marcel Bruch Handelsregister: Darmstadt HRB 91940 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Error reporter and third-party code
Am 24.07.2015 um 17:36 schrieb Gunnar Wagenknecht gun...@wagenknecht.org: Am 24.07.2015 um 08:27 schrieb Marcel Bruch marcel.br...@codetrails.com: Most reports mentioning Sapphire are from the namespaces oracle.eclipse.tools.* and com.liferay.* Some reports show that Sapphire clients even do not follow the bundle name to package name conventions. Neither oracle.eclipse.* nor com.liferay.* seem to be open source namespaces. How did you get that information? I thought it's currently not submitted to Eclipse.org or any other entity? it’s actually a sloppy implementation in the bundle guessing section of an error report. Also the eclipse product/build-ids are not restricted which contain information whther a problem was reported by the Spring Tools Suite for example. Marcel -Gunnar -- Gunnar Wagenknecht gun...@wagenknecht.org, http://guw.io/ ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Codetrails GmbH The knowledge transfer company Robert-Bosch-Str. 7, 64293 Darmstadt Phone: +49-6151-276-7092 Mobile: +49-179-131-7721 http://www.codetrails.com/ Managing Director: Dr. Marcel Bruch Handelsregister: Darmstadt HRB 91940 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Error reporter and third-party code
Am 24.07.2015 um 08:27 schrieb Marcel Bruch marcel.br...@codetrails.com: Most reports mentioning Sapphire are from the namespaces oracle.eclipse.tools.* and com.liferay.* Some reports show that Sapphire clients even do not follow the bundle name to package name conventions. Neither oracle.eclipse.* nor com.liferay.* seem to be open source namespaces. How did you get that information? I thought it's currently not submitted to Eclipse.org or any other entity? -Gunnar -- Gunnar Wagenknecht gun...@wagenknecht.org, http://guw.io/ ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Buildship in SR1
Hi Pascal Thanks for thinking about Buildship. Interestingly, right this morning, I had a 1-hour chat with Markus re: inclusion of Buildship in SR1. We got a lot of valuable information from him and we (Donat and i) will start tackling it beginning of next week. I think we are in good shape to make it for SR1. Etienne On 24.07.2015, at 19:18, Pascal Rapicault pas...@rapicorp.com wrote: Do you happen to know where the team is at wrt producing a build for consumption in the aggregator? I'm just asking because RC1 [1] is coming quickly (August 14th) and so it may be better to work out the problems sooner rather than later. Otherwise I can imagine the project being put at risk again. [1] - https://wiki.eclipse.org/Mars/Simultaneous_Release_Plan#SR1 On 07/24/2015 07:11 PM, Markus Knauer wrote: Yep, that's the plan if I may answer this question. Regards, Markus On 24 July 2015 at 18:43, Pascal Rapicault pas...@rapicorp.com wrote: Hey, IIRC back in April / May, it was decided that Buildship (Gradle integration in Eclipse) would be added to Mars SR1. Is this still the plan? Pascal ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Error reporter and third-party code
On 24 Jul 2015, at 17:27, Marcel Bruch wrote: I think those clients (which currently make ~28% of the error reports) should actually sign-up and subscribe to their error reports How do I subscribe to error reports that are filtered ? - or set up their own error collection to review and fix their issues themselves. ...adding another layer of error reporting will give even worse end-user experience imo - i.e. how do I know that eclipse error reporter haven't reported it ? /max http://about.me/maxandersen ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Buildship in SR1
Do you happen to know where the team is at wrt producing a build for consumption in the aggregator? I'm just asking because RC1 [1] is coming quickly (August 14th) and so it may be better to work out the problems sooner rather than later. Otherwise I can imagine the project being put at risk again. [1] - https://wiki.eclipse.org/Mars/Simultaneous_Release_Plan#SR1 On 07/24/2015 07:11 PM, Markus Knauer wrote: Yep, that's the plan if I may answer this question. Regards, Markus On 24 July 2015 at 18:43, Pascal Rapicault pas...@rapicorp.com mailto:pas...@rapicorp.com wrote: Hey, IIRC back in April / May, it was decided that Buildship (Gradle integration in Eclipse) would be added to Mars SR1. Is this still the plan? Pascal ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] usage data collection for RCP apps
I am pretty sure we are not allowed to collect usage data. Wayne still can't decide the policy around this [1]. I have some opensource code for out-of-eclipse usage collection which I use with my m2e extensions, if you are interested. [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=413169 -- Regards, Igor On Fri, Jul 24, 2015, at 01:34 PM, Scott Lewis wrote: Hi, My apologies for not paying attention, but is there anything of the Usage data collection work that could be used within an RCP app? (As opposed to Eclipse) If so, is there any experiences and/or documentation that could be shared? Thanksinadvance, Scott ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Buildship in SR1
Hey, IIRC back in April / May, it was decided that Buildship (Gradle integration in Eclipse) would be added to Mars SR1. Is this still the plan? Pascal ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Buildship in SR1
Yep, that's the plan if I may answer this question. Regards, Markus On 24 July 2015 at 18:43, Pascal Rapicault pas...@rapicorp.com wrote: Hey, IIRC back in April / May, it was decided that Buildship (Gradle integration in Eclipse) would be added to Mars SR1. Is this still the plan? Pascal ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] usage data collection for RCP apps
Hi, My apologies for not paying attention, but is there anything of the Usage data collection work that could be used within an RCP app? (As opposed to Eclipse) If so, is there any experiences and/or documentation that could be shared? Thanksinadvance, Scott ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] usage data collection for RCP apps
On 24 Jul 2015, at 19:34, Scott Lewis wrote: Hi, My apologies for not paying attention, but is there anything of the Usage data collection work that could be used within an RCP app? (As opposed to Eclipse) If so, is there any experiences and/or documentation that could be shared? if you google for JBoss Tools usage you'll see what we've done. main entry page is at http://tools.jboss.org/usage/ with links to docs, code etc. Also gave a talk at eclipse cons about it http://www.slideshare.net/maxandersen/google-analytics-for-eclipse-plugins svn plugins use it too. it is starting to hit it limits on a free google analytics account though - so just don't be too popular and it works fine ;) Thanksinadvance, Scott ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev /max http://about.me/maxandersen ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] question about moving up release date
Wayne is on holidays until Aug. 3. If you can't manage to delete it and create a new one, please drop a line to webmas...@eclipse.org. We probably can, otherwise we can edit the SQL backend. Denis On 24/07/15 03:16 PM, Scott Lewis wrote: Wayne appears to be inaccessible so I'll ask this list: Is it possible to edit/change (e.g. move up) a scheduled release in the meta-data editor? If so, how? Alternatively, I could delete the existing release and create a new one with the correct date, but I can't see a way to delete a release. Thanks, Scott ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Error reporter and third-party code
I think those clients (which currently make ~28% of the error reports) should actually sign-up and subscribe to their error reports Liferay would love to sign up, just point the way. On Fri, Jul 24, 2015 at 1:09 PM, Konstantin Komissarchik konstantin.komissarc...@oracle.com wrote: I dug a bit deeper into Sapphire error reports. My conclusion: Adding more open source namespaces wont help much in your (and Nebula’s) case. Most reports mentioning Sapphire are from the namespaces oracle.eclipse.tools.* and com.liferay.* Some reports show that Sapphire clients even do not follow the bundle name to package name conventions. Neither oracle.eclipse.* nor com.liferay.* seem to be open source namespaces. RedHat is an adopter of Sapphire and Liferay is LGPL ( http://www.liferay.com/downloads/liferay-portal/license-ce) Regarding your popup question: I sense that asking a user for permission whenever a non-eclipse namespace was discovered in the trace will quickly be very annoying. My thinking is that you only ask regarding the first two or three segments of the namespace and then you persist the choice. So if we already asked you about oracle.eclipse namespace, you aren’t going to be bugged again regarding this. An average user is unlikely to have that many plugins from varied sources installed for these popups to be a big annoyance. We only send errors that are logged by eclipse.org / apache.org plugins. However, it's likely that com.liferay will log errors that reference Sapphire classes. Following your previous arguments, you would be interested in those as well. I am surprised to hear that we don’t report these today. Here we get into trouble. If we do so, we would need to send every error report that mentions at least one Eclipse class to eclipse.org. if we do so, users will notice dozens of „an error was logged“ popup appears per day (b/c some 3rd party plugins causes trouble) and will conclude that Eclipse is extremely buggy. I disagree with the conclusions you draw in these statements. 1. The identity of the party that logged the error is not a predictor of which party is responsible for the error, as clearly evident by the captured error reports that we have. All you know is where the catch clause was located. 2. Users view Eclipse as a whole, in comparison to other IDE choices. They don’t really care that much that the party that’s causing them grief is a third-party plugin, especially if it’s an essential plugin to get Eclipse to fulfill a given function. I’m not sure I wanna go down this road. At some point we need to draw a line between error that are caused by third-party plugins (like Liferay or Oracle) and those caused by Eclipse plugins. There is no automated system for making that determination in a reliable manner. We should be erring on the side of capturing more error reports as that’s the best way to ensure that more errors get fixed. I think those clients (which currently make ~28% of the error reports) should actually sign-up and subscribe to their error reports - or set up their own error collection to review and fix their issues themselves. Think of the user experience if every third-party plugin operated their own error collection system, with notices and approvals and every system operating slightly differently. That’s a pretty good recipe for some unhappy users. Ideally, I’d like to see Eclipse error reporting system opened to third-party plugin builders, so they can register, get notices, the whole bit. Absent that, I’d like to be able to at least manually help Sapphire’s adopters improve their plugins and help them help me to improve Sapphire. Thanks, - Konstantin *From:* cross-project-issues-dev-boun...@eclipse.org [mailto: cross-project-issues-dev-boun...@eclipse.org] *On Behalf Of *Marcel Bruch *Sent:* Friday, July 24, 2015 8:27 AM *To:* Cross project issues *Subject:* Re: [cross-project-issues-dev] Error reporter and third-party code Konstantin, I dug a bit deeper into Sapphire error reports. My conclusion: Adding more open source namespaces wont help much in your (and Nebula’s) case. Most reports mentioning Sapphire are from the namespaces oracle.eclipse.tools.* and com.liferay.* Some reports show that Sapphire clients even do not follow the bundle name to package name conventions. Neither oracle.eclipse.* nor com.liferay.* seem to be open source namespaces. Regarding your popup question: I sense that asking a user for permission whenever a non-eclipse namespace was discovered in the trace will quickly be very annoying. The next thing to consider: We only send errors that are logged by eclipse.org / apache.org plugins. However, it's likely that com.liferay will log errors that reference Sapphire classes. Following your previous arguments, you would be interested in those as well.
[cross-project-issues-dev] question about moving up release date
Wayne appears to be inaccessible so I'll ask this list: Is it possible to edit/change (e.g. move up) a scheduled release in the meta-data editor? If so, how? Alternatively, I could delete the existing release and create a new one with the correct date, but I can't see a way to delete a release. Thanks, Scott ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] question about moving up release date
Hi, after you login, you go to your project page and select the release you want to change. The press the Edit button on the left of the black toolbar. Then open the The Basics section and change the date in Release Date. Marc From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Scott Lewis [sle...@composent.com] Sent: July 24, 2015 3:16 PM To: Cross project issues Subject: [cross-project-issues-dev] question about moving up release date Wayne appears to be inaccessible so I'll ask this list: Is it possible to edit/change (e.g. move up) a scheduled release in the meta-data editor? If so, how? Alternatively, I could delete the existing release and create a new one with the correct date, but I can't see a way to delete a release. Thanks, Scott ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] question about moving up release date
Oh and to delete a release, you also got to Edit and at the bottom there is a red Delete button. From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Marc Khouzam [marc.khou...@ericsson.com] Sent: July 24, 2015 3:32 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] question about moving up release date Hi, after you login, you go to your project page and select the release you want to change. The press the Edit button on the left of the black toolbar. Then open the The Basics section and change the date in Release Date. Marc From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Scott Lewis [sle...@composent.com] Sent: July 24, 2015 3:16 PM To: Cross project issues Subject: [cross-project-issues-dev] question about moving up release date Wayne appears to be inaccessible so I'll ask this list: Is it possible to edit/change (e.g. move up) a scheduled release in the meta-data editor? If so, how? Alternatively, I could delete the existing release and create a new one with the correct date, but I can't see a way to delete a release. Thanks, Scott ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Error reporter and third-party code
I dug a bit deeper into Sapphire error reports. My conclusion: Adding more open source namespaces wont help much in your (and Nebula’s) case. Most reports mentioning Sapphire are from the namespaces oracle.eclipse.tools.* and com.liferay.* Some reports show that Sapphire clients even do not follow the bundle name to package name conventions. Neither oracle.eclipse.* nor com.liferay.* seem to be open source namespaces. RedHat is an adopter of Sapphire and Liferay is LGPL (http://www.liferay.com/downloads/liferay-portal/license-ce) Regarding your popup question: I sense that asking a user for permission whenever a non-eclipse namespace was discovered in the trace will quickly be very annoying. My thinking is that you only ask regarding the first two or three segments of the namespace and then you persist the choice. So if we already asked you about oracle.eclipse namespace, you aren’t going to be bugged again regarding this. An average user is unlikely to have that many plugins from varied sources installed for these popups to be a big annoyance. We only send errors that are logged by eclipse.org / apache.org plugins. However, it's likely that com.liferay will log errors that reference Sapphire classes. Following your previous arguments, you would be interested in those as well. I am surprised to hear that we don’t report these today. Here we get into trouble. If we do so, we would need to send every error report that mentions at least one Eclipse class to eclipse.org. if we do so, users will notice dozens of „an error was logged“ popup appears per day (b/c some 3rd party plugins causes trouble) and will conclude that Eclipse is extremely buggy. I disagree with the conclusions you draw in these statements. 1. The identity of the party that logged the error is not a predictor of which party is responsible for the error, as clearly evident by the captured error reports that we have. All you know is where the catch clause was located. 2. Users view Eclipse as a whole, in comparison to other IDE choices. They don’t really care that much that the party that’s causing them grief is a third-party plugin, especially if it’s an essential plugin to get Eclipse to fulfill a given function. I’m not sure I wanna go down this road. At some point we need to draw a line between error that are caused by third-party plugins (like Liferay or Oracle) and those caused by Eclipse plugins. There is no automated system for making that determination in a reliable manner. We should be erring on the side of capturing more error reports as that’s the best way to ensure that more errors get fixed. I think those clients (which currently make ~28% of the error reports) should actually sign-up and subscribe to their error reports - or set up their own error collection to review and fix their issues themselves. Think of the user experience if every third-party plugin operated their own error collection system, with notices and approvals and every system operating slightly differently. That’s a pretty good recipe for some unhappy users. Ideally, I’d like to see Eclipse error reporting system opened to third-party plugin builders, so they can register, get notices, the whole bit. Absent that, I’d like to be able to at least manually help Sapphire’s adopters improve their plugins and help them help me to improve Sapphire. Thanks, - Konstantin From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Marcel Bruch Sent: Friday, July 24, 2015 8:27 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] Error reporter and third-party code Konstantin, I dug a bit deeper into Sapphire error reports. My conclusion: Adding more open source namespaces wont help much in your (and Nebula’s) case. Most reports mentioning Sapphire are from the namespaces oracle.eclipse.tools.* and com.liferay.* Some reports show that Sapphire clients even do not follow the bundle name to package name conventions. Neither oracle.eclipse.* nor com.liferay.* seem to be open source namespaces. Regarding your popup question: I sense that asking a user for permission whenever a non-eclipse namespace was discovered in the trace will quickly be very annoying. The next thing to consider: We only send errors that are logged by eclipse.org / apache.org plugins. However, it's likely that com.liferay will log errors that reference Sapphire classes. Following your previous arguments, you would be interested in those as well. Here we get into trouble. If we do so, we would need to send every error report that mentions at least one Eclipse class to eclipse.org. if we do so, users will notice dozens of „an error was logged“ popup appears per day (b/c some 3rd party plugins causes trouble) and will conclude that Eclipse is extremely
Re: [cross-project-issues-dev] Buildship in SR1
Hi Etienne, Good to hear. Good luck! Pascal On 07/24/2015 07:30 PM, Etienne Studer wrote: Hi Pascal Thanks for thinking about Buildship. Interestingly, right this morning, I had a 1-hour chat with Markus re: inclusion of Buildship in SR1. We got a lot of valuable information from him and we (Donat and i) will start tackling it beginning of next week. I think we are in good shape to make it for SR1. Etienne On 24.07.2015, at 19:18, Pascal Rapicault pas...@rapicorp.com mailto:pas...@rapicorp.com wrote: Do you happen to know where the team is at wrt producing a build for consumption in the aggregator? I'm just asking because RC1 [1] is coming quickly (August 14th) and so it may be better to work out the problems sooner rather than later. Otherwise I can imagine the project being put at risk again. [1] - https://wiki.eclipse.org/Mars/Simultaneous_Release_Plan#SR1 On 07/24/2015 07:11 PM, Markus Knauer wrote: Yep, that's the plan if I may answer this question. Regards, Markus On 24 July 2015 at 18:43, Pascal Rapicault pas...@rapicorp.com mailto:pas...@rapicorp.com wrote: Hey, IIRC back in April / May, it was decided that Buildship (Gradle integration in Eclipse) would be added to Mars SR1. Is this still the plan? Pascal ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] OAuth 2.0 Eclipse Services
On Fri, Jul 24, 2015 at 10:34 AM, Marcel Bruch marcel.br...@codetrails.com wrote: Greetings cross-projects, for the error reporting I’d like to give committers/reporters the ability to store personal preferences and get access to the errors they sent in the past, current status of these problems etc. For that I need to authenticate users by email address. One (half-baked) idea is to allow users to register using some OAuth provider like Google, Github or - if supported - eclipse.org. My question is, does any eclipse project have OAuth working in their code base (plugin or server)? Which libraries do you use and what else should we be aware of? The gerrit OAuth plugins https://github.com/davido/gerrit-oauth-provider/ https://gerrit.googlesource.com/plugins/cfoauth/ use the Scribe library [1] to support OAuth authentication against - Google - Github - CloudFoundry UAA [2] OAuth servers. When implementing the plugin for CloudFoundry UAA we found that Scribe doesn't really support it despite the fact that UAA seems to be the implementation closest to the OAuth specification. Hence we implemented the cfoauth Gerrit plugin to close the gap for Gerrit. Apache Oltu is another Java based OAuth implementation (both client and server) listed on http://oauth.net/2/ which seems more powerful than Scribe. Though we have no practical experience with this implementation. [1] https://github.com/fernandezpablo85/scribe-java [2] https://github.com/cloudfoundry/uaa [3] http://oltu.apache.org/ -Matthias ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
