Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version
Yeah, I think we're OK since we depend on the eclipse.sdk feature which brings in the right version of JDT. I just saw OTDT fly by with another error message, but that seemed unrelated and is now gone. But I do remember a lot of concern when this came along and Max's question is a valid one to ask. We do have two JDT's in the simrel repo. That's pretty scary. Doug From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Igor Fedorenko [i...@ifedorenko.com] Sent: Friday, June 27, 2014 10:35 AM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version FWIW, we build m2e against simrel repository and don't have any problems. http://ci.tesla.io:8080/view/m2e/job/m2eclipse-core/ -- Regards, Igor On 2014-06-27, 10:27, Max Rydahl Andersen wrote: On 26 Jun 2014, at 10:49, Doug Schaefer wrote: We build directly against the Eclipse one. Does that mean we can't do that any more? you haven't been able to do that for ~2 years. Michael - do you recall why ODT keeps getting be allowed in the release train ? Thought we opened a bugzilla on this a while back since it really does not seem sane a plugin on the release train is allowed to mutate one of the plugins. /max Doug From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Mickael Istria [mist...@redhat.com] Sent: Thursday, June 26, 2014 10:45 AM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version On 06/26/2014 04:42 PM, Doug Schaefer wrote: I just noticed this in our product builds now too. What was the solution? I imagine this is going to affect everyone that includes JDT in their product, no? FYI, for JBoss Tools and JBoss Developer Studio, we do have a mirror of the Luna repository from where we explicitly exclude the OTDT patch. And since we consume this repository, we are sure we always get the JDT one. https://github.com/jbosstools/jbosstools-download.jboss.org/blob/master/jbosstools/updates/requirements/luna/build.xml#L32 HTH -- Mickael Istria Eclipse developer at JBoss, by Red Hathttp://www.jboss.org/tools My bloghttp://mickaelistria.wordpress.com - My Tweetshttp://twitter.com/mickaelistria ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org 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 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version
No one doubts your commitment to JDT. You've been great helping them out. And we all appreciate that. I guess the real question, is that if someone ends up with the OTDT version of the JDT, do bad things happen? I agree you followed all that was asked of you, but I think we assumed and I do hope you've accomplished what's best for the community at large. What were the plans to mitigate these issues? Thanks, Doug. From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Stephan Herrmann [stephan.herrm...@berlin.de] Sent: Friday, June 27, 2014 12:16 PM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version On 06/27/2014 05:34 PM, Doug Schaefer wrote: But I do remember a lot of concern when this came along and Max's question is a valid one to ask. We do have two JDT's in the simrel repo. That's pretty scary. Doug OK, I had to dig 3+ years into the past to find the original agreement. Here are the main references for your convenience: The general case was discussed in this bug: https://bugs.eclipse.org/330312 Conclusion: no new rules needed for such a rare situation. The special case should be handled via a request for exception. Request for exception was raised via tools PMC: http://dev.eclipse.org/mhonarc/lists/tools-pmc/msg01491.html The result was to make the decision depend on an agreement between JDT and Object Teams. This reflects the discussion in both tools PMC and Planning Council. This agreement has been achieved in a phone call between Dani and myself. After that call, I brought the request to the eclipse PMC: http://dev.eclipse.org/mhonarc/lists/eclipse-pmc/msg01338.html In that thread you find Dani's confirmation, four +1 votes, and no 0 or -1 votes. Aside from formal process, need I assure anybody on this list, how much I care about the quality and reputation of JDT? best, Stephan ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Remove CVS from Eclipse packages?
Then again, maybe removing it will give Orbit incentive to get off of CVS. Doug. From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Oberhuber, Martin [martin.oberhu...@windriver.com] Sent: Thursday, June 26, 2014 5:22 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] Remove CVS from Eclipse packages? I would suggest keeping it in “Standard” as long as the Eclipse Orbit project still uses CVS. “Standard” should continue being the one-stop-shop for self-hosted development of Eclipse Plugins. The CVS adapter is really small enough to not cause any harm IMHO. Moving it out of the other packages, and offering CVS on the Marketplace instead, is a good idea. Marketplace Statistics will also give some idea how many people still want it. Thanks, Martin -- Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River direct +43.662.457915.85 fax +43.662.457915.6 From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Moritz Eysholdt Sent: Thursday, June 26, 2014 11:16 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] Remove CVS from Eclipse packages? +1 yes! let’s get rid of this dinosaur! regards, Moritz On 26 Jun 2014, at 10:24, Mickael Istria mist...@redhat.commailto:mist...@redhat.com wrote: Hi all, Now that CVS is only used by 3.7% of people according to latest Eclipse survey, wouldn't it make sense to kick it out of default Eclipse packages to avoid showing the useless CVS entries (in show view or import for example) to the remaining 96.3% of Eclipse users? Instead, we could think of providing CVS on marketplace. What do you think about it? -- Mickael Istria Eclipse developer at JBoss, by Red Hathttp://www.jboss.org/tools My bloghttp://mickaelistria.wordpress.com/ - My Tweetshttp://twitter.com/mickaelistria ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Remove CVS from Eclipse packages?
I've added my comment to that rather old and silent bug. A lot of us when building such things for our products just use maven central, the maven-build-plugin, and tycho to create a p2 repo. Waiting to hear why that's not acceptable. Doug From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Markus Keller [markus_kel...@ch.ibm.com] Sent: Thursday, June 26, 2014 3:13 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] Remove CVS from Eclipse packages? What's the alternative for Orbit? Git is not really suited, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=349048#c4 and the rest of that bug. Please continue discussions about Orbit there. Markus From:Doug Schaefer dschae...@qnx.com To:Cross project issues cross-project-issues-dev@eclipse.org Date:2014-06-26 16:10 Subject:Re: [cross-project-issues-dev] Remove CVS from Eclipse packages? Sent by:cross-project-issues-dev-boun...@eclipse.org Then again, maybe removing it will give Orbit incentive to get off of CVS. Doug. From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Oberhuber, Martin [martin.oberhu...@windriver.com] Sent: Thursday, June 26, 2014 5:22 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] Remove CVS from Eclipse packages? I would suggest keeping it in “Standard” as long as the Eclipse Orbit project still uses CVS. “Standard” should continue being the one-stop-shop for self-hosted development of Eclipse Plugins. The CVS adapter is really small enough to not cause any harm IMHO. Moving it out of the other packages, and offering CVS on the Marketplace instead, is a good idea. Marketplace Statistics will also give some idea how many people still want it. Thanks, Martin -- Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River direct +43.662.457915.85 fax +43.662.457915.6 From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Moritz Eysholdt Sent: Thursday, June 26, 2014 11:16 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] Remove CVS from Eclipse packages? +1 yes! let’s get rid of this dinosaur! regards, Moritz On 26 Jun 2014, at 10:24, Mickael Istria mist...@redhat.commailto:mist...@redhat.com wrote: Hi all, Now that CVS is only used by 3.7% of people according to latest Eclipse survey, wouldn't it make sense to kick it out of default Eclipse packages to avoid showing the useless CVS entries (in show view or import for example) to the remaining 96.3% of Eclipse users? Instead, we could think of providing CVS on marketplace. What do you think about it? -- Mickael Istria Eclipse developer at JBoss, by Red Hathttp://www.jboss.org/tools My bloghttp://mickaelistria.wordpress.com/ - My Tweetshttp://twitter.com/mickaelistria ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Luna RC4 staging repo is complete
Really, I just changed the one line in my target file and checked it in for all my builds. I love Tycho for that :) From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Igor Fedorenko [i...@ifedorenko.com] Sent: Thursday, June 19, 2014 10:29 AM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Luna RC4 staging repo is complete It will take me couple of hours to switch all my CI jobs from releases/luna to releases/staging and make sure they still work, and another couple of hours to switch them back to releases/luna next week. Not a huge amount of time, but I'd prefer not to have to spend it. If people are passionate about release event, lets publish all M and RC builds to milestones/celestial-object and populate releases/celestial-object only after the release has been declared. -- Regards, Igor On 2014-06-19, 10:02, Doug Schaefer wrote: For what it's worth, I'm testing our internal product builds against releases/staging, and we're fine with that. We've probably spent more time on this thread than it does to change your target to point at it. Doug. From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Igor Fedorenko [i...@ifedorenko.com] Sent: Thursday, June 19, 2014 9:28 AM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Luna RC4 staging repo is complete I don't believe Tycho approach (and Maven/Nexus in general) is a good role model. I also don't think it applies to symrel process. As a symrel consumer, I know that d.e.o/releases/celestial-object is the place to get latest published M/RC build towards the next release and this is what I am told to use throughout yearly release cycle. Few weeks before the release, however, I need to switch to another repository to test with the final RC. This is rather surprising (and I am quite certain I'll forget about this by next May) and requires non-trivial amount of work on my part because I need to update all my build scripts and/or CI jobs to use the staging repository. If you are really concerned about releasing final RC to releases/celestial-object couple of weeks earlier, then I think we need separate stable prerelease repository URL. This is what we do for m2e, for example. All M and RC builds go to the same milestones/version/ repository and the final RC is promoted to releases/version repo when the release is declared. Personally, though, I find concerns about releasing early quite silly. To me release is purely marketing event. As a developer I write code and publish builds as they become available. One of the published builds is later declared a release, but this has little/no impact on my development workflow. -- Regards, Igor On 2014-06-19, 8:21, David M Williams wrote: The reason we don't do that is because that would be the same as releasing it ... that, and the URL /release/luna is built in to all prior Luna milestones and candidates, so people with auto update set would all start hitting 'download.eclipse.org' the moment it was there, before there was opportunity to mirror. I think it's very common for many projects (such as Tycho) to be available in a staging location for a period, before officially moving to the released location. Perhaps this FAQ would help? http://wiki.eclipse.org/SimRel/Simultaneous_Release_FAQ#What.27s_the_best_way_to_test_with_the_staging_repository.3F Thanks for suggesting ways to improve the process, though. From: Igor Fedorenko i...@ifedorenko.com To: cross-project-issues-dev@eclipse.org, Date: 06/19/2014 07:55 AM Subject: Re: [cross-project-issues-dev] Luna RC4 staging repo is complete Sent by: cross-project-issues-dev-boun...@eclipse.org Little late to the party, but I'd like to suggest adding RC4 to Luna composite and making this part of symrel process going forward. By hiding RC4 under obscure URL we artificially limit amount of testing it gets and make it harder for downstream projects validate their code will still work yearly release comes live next week. -- Regards, Igor On 2014-06-11, 23:52, David M Williams wrote: http://download.eclipse.org/releases/staging/ As I am sure you all know, this is our final aggregation build for Luna, unless a blocking issue is found. I always like to emphasize, that, at this point, a blocking issue that would lead to a re-spin has to be more than a typical bad problem for a one project ... but more along the lines of something that destroys all data in a project or workspace or prevents installs or updates of other projects from occurring or that sort of thing. If you do find a bad bug that effects just your
Re: [cross-project-issues-dev] Eclipse SDK plugin and Luna rc1
I wonder if it's getting confused with the product IU that get's created for the SDK. It has the same name. In fact I was going to try and figure out how you did that since category.xml files usually only support bundles and features, not these magic product IUs. The workflow is so much nicer if the product is available in the p2 UI. Now I've only seen them in the Eclipse project downloads, not in /releases. And they have the ids: org.eclipse.sdk.ide. If that isn't what you're referring to, then never mind :). From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of David M Williams [david_willi...@us.ibm.com] Sent: Friday, May 30, 2014 12:30 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] Eclipse SDK plugin and Luna rc1 I'm not sure that bundle is ever in the downloadable standard package. Have you found it there in the past? It is the branding bundle for the Eclipse SDK ... and the Eclipse Standard package would have it own branding bundle. What do you need it for? (I only ask, to know what to recommend to help you). There might be confusion between Eclipse Standard and the previously provided Eclipse Classic ... they are not quite the same thing. Eclipse Classic was literally the Eclipse SDK, but Eclipse Standard has a few things added, so is a new, different product. HTH Thanks, From:bzendagui boubekeur.zenda...@obeo.fr To:cross-project-issues-dev@eclipse.org, Date:05/30/2014 09:39 AM Subject:Re: [cross-project-issues-dev] Eclipse SDK plugin and Luna rc1 Sent by:cross-project-issues-dev-boun...@eclipse.org Hello Markus, I'm looking for the bundle org.eclipse.sdk_4.4.0.qualifier. It is not available in the eclipse/plugin folder of Eclipse Luna i downloaded from https://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/luna/RC1/eclipse-standard-luna-RC1-win32.zip. So i tried the command ss org.eclipse.sdk in OSGI console and there is no result. The Feature org.eclipse.sdk is not available too in the eclipse/feature. So i will wait for RC2. Best regards, Boubekeur Zendagui Date: Wed, 28 May 2014 17:59:35 +0200 From: Markus Knauer mkna...@eclipsesource.com To: Cross project issues cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Eclipse SDK plugin and Luna rc1 Message-ID: cae0b9awuvav7rxlczkke-04vcrgmm-fn2qgo-szdtalyogn...@mail.gmail.com Content-Type: text/plain; charset=utf-8 Are you looking for the *bundle* org.eclipse.sdk_4.4.0.v20140515-1230.jar [1], or for the *SDK download* from the Eclipse Platform team [2]? [1] http://download.eclipse.org/releases/luna/201405230900/plugins/org.eclipse.sdk_4.4.0.v20140515-1230.jar [2] http://download.eclipse.org/eclipse/downloads/drops4/S-4.4RC2-201405221330/ The link you were using points to the Eclipse Standard package from EPP. Regards, Markus On Wed, May 28, 2014 at 5:10 PM, bzendagui boubekeur.zenda...@obeo.frwrote: Hello, The plugin org.eclipse.sdk is not available in Eclipse Standard Luna rc1. Is this normal ? Here is the link i used to download it (https://www.eclipse.org/ downloads/download.php?file=/technology/epp/downloads/ release/luna/RC1/eclipse-standard-luna-RC1-win32.zip). Best regards, Boubekeur Zendagui ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] IP Logs for Luna are due tomorrow
Also, do we raise bugs when we see issues? There are at least two former committers who's contributions are showing up in the Contributors section for CDT and I can't see a way on the page to make the correction. Doug. From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Greg Watson [g.wat...@computer.org] Sent: Thursday, May 22, 2014 4:29 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] IP Logs for Luna are due tomorrow I have a couple of questions about the logs: 1. How do you control which git repos are included? It allows you to adjust the set of projects, but how does it know which repos are associated with a project? 2. What are we expected to do with this list? For PTP, the Contributors and Their Contributions section contains over 4000 entries. Are we expected to review them all? Thanks, Greg On May 22, 2014, at 4:08 PM, Markus Knauer wrote: If I'm not mistaken this one should be the correct URL for you: http://eclipse.org/projects/ip_log.php?projectid=modeling.mmt.qvtd Regards, Markus On Thu, May 22, 2014 at 9:47 PM, Ed Willink e...@willink.me.ukmailto:e...@willink.me.uk wrote: Hi I must be dozy. I thought the IP tool had moved from the portal to the PMI, but I can't find it in either location. Regards Ed Willink On 22/05/2014 20:36, Wayne Beaton wrote: Greetings folks. Gentle reminder that IP Logs for Luna are due tomorrow. If circumstances require an extension, please let me know ASAP. Thanks, Wayne -- Wayne Beaton Director of Open Source Projects, The Eclipse Foundationhttp://www.eclipse.org/ Learn about Eclipse Projectshttp://www.eclipse.org/projects Mail Attachment.jpeghttp://www.eclipsecon.org/france2014 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev No virus found in this message. Checked by AVG - www.avg.comhttp://www.avg.com/ Version: 2014.0.4592 / Virus Database: 3950/7542 - Release Date: 05/22/14 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] IP Logs for Luna are due tomorrow
I already have, check your inbox. :) I'm wondering if it's the same problem as Greg's. Is anyone else seeing this, where committers commits are showing up in the contributions list? Doug. From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Wayne Beaton [wa...@eclipse.org] Sent: Thursday, May 22, 2014 9:28 PM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] IP Logs for Luna are due tomorrow Open a bug against Community/IP Log Tool The problem is likely that the commits use email addresses that we don't know about. This sometimes happens after committers change jobs and email addresses. Wayne On 05/22/2014 04:35 PM, Doug Schaefer wrote: Also, do we raise bugs when we see issues? There are at least two former committers who's contributions are showing up in the Contributors section for CDT and I can't see a way on the page to make the correction. Doug. From: cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org] on behalf of Greg Watson [g.wat...@computer.orgmailto:g.wat...@computer.org] Sent: Thursday, May 22, 2014 4:29 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] IP Logs for Luna are due tomorrow I have a couple of questions about the logs: 1. How do you control which git repos are included? It allows you to adjust the set of projects, but how does it know which repos are associated with a project? 2. What are we expected to do with this list? For PTP, the Contributors and Their Contributions section contains over 4000 entries. Are we expected to review them all? Thanks, Greg On May 22, 2014, at 4:08 PM, Markus Knauer wrote: If I'm not mistaken this one should be the correct URL for you: http://eclipse.org/projects/ip_log.php?projectid=modeling.mmt.qvtd Regards, Markus On Thu, May 22, 2014 at 9:47 PM, Ed Willink e...@willink.me.ukmailto:e...@willink.me.uk wrote: Hi I must be dozy. I thought the IP tool had moved from the portal to the PMI, but I can't find it in either location. Regards Ed Willink On 22/05/2014 20:36, Wayne Beaton wrote: Greetings folks. Gentle reminder that IP Logs for Luna are due tomorrow. If circumstances require an extension, please let me know ASAP. Thanks, Wayne -- Wayne Beaton Director of Open Source Projects, The Eclipse Foundationhttp://www.eclipse.org/ Learn about Eclipse Projectshttp://www.eclipse.org/projects Mail Attachment.jpeghttp://www.eclipsecon.org/france2014 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev No virus found in this message. Checked by AVG - www.avg.comhttp://www.avg.com/ Version: 2014.0.4592 / Virus Database: 3950/7542 - Release Date: 05/22/14 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Wayne Beaton Director of Open Source Projects, The Eclipse Foundationhttp://www.eclipse.org Learn about Eclipse Projectshttp://www.eclipse.org/projects [EclipseCon France 2014]http://www.eclipsecon.org/france2014 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Contribute project styling for the dark theme
BTW, love how easy this is. Thanks guys! Doug. From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Lars Vogel [lars.vo...@gmail.com] Sent: Tuesday, May 06, 2014 2:43 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] Contribute project styling for the dark theme See https://bugs.eclipse.org/bugs/show_bug.cgi?id=433605 or https://git.eclipse.org/r/26006 for a example for JDT 2014-05-05 10:22 GMT+02:00 Daniel Rolka daniel.ro...@pl.ibm.commailto:daniel.ro...@pl.ibm.com: Hi Doug, Is there documentation on how to do that? I'm going to prepare the WIKI page with details about the styling of the preferences via CSS by the end of the week. I will send the link to the mailing groups thanks, Daniel From: Doug Schaefer dschae...@qnx.commailto:dschae...@qnx.com To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org, Date: 04/30/2014 05:31 PM Subject:Re: [cross-project-issues-dev] Contribute project styling for the darktheme Sent by: cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org One of the bugs mentioned there's a way for plug-ins to extend the theme. I'd rather non-Eclipse Project projects, like CDT, do it this way. Is there documentation on how to do that? I couldn't quite figure it out from yours and Tom's comments. Thanks, Doug. From: cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org] on behalf of Lars Vogel [lars.vo...@gmail.commailto:lars.vo...@gmail.com] Sent: Wednesday, April 30, 2014 12:28 AM To: cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: [cross-project-issues-dev] Contribute project styling for the dark theme Hi, in the recent integration builds (or M7) the platform team supports styling of UI related properties. This allows projects to contribute reasonable defaults for syntax highlighting for the integrated dark theme. See the attached files. xml-editor.png shows how a not styled editor would look like and colorsyntaxhightlighs.png shows the styled Java editor. I could like to encourage projects to contribute their settings to the dark theme. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=433475 for the general discussion and https://bugs.eclipse.org/bugs/show_bug.cgi?id=433605 for an example how to style JDT (which I plan to contribute for RC1, via 433605). For several projects I created already bugs to contribute that. If you are interested, please create a bug and add it to 433475. Best regards, Lars ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Kepler SR3 for Java 8?
I'm sorry, but I only know about the JDT patch, and a pretty decent p2 site has been created to make it really easy to install. No building required. I'm happily using it to work on JavaFX stuff. What's in the WTP patch? And I'm not even sure Tycho has support for Java 8 yet. I appreciate your concern, but I'd also like to hear from a few others before we (the planning council and EPP maintainers) start the significant effort to respin Kepler, as opposed to making Luna, available in only 3 months, our first class Java 8 tool. Doug. From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Konstantin Komissarchik [konstantin.komissarc...@oracle.com] Sent: Monday, March 24, 2014 12:05 PM To: 'Cross project issues' Subject: Re: [cross-project-issues-dev] Kepler SR3 for Java 8? I don't see evidence to back such a conjecture. One cannot assume that Java sophistication implies sophistication or desire to build and install Eclipse patches. One cannot assume that immediate interest in Java 8 even implies any level of sophistication (see students). In fact, I would expect that a large number of developers who are not tied by JVM backwards compatibility requirements will be moving to Java 8 in the next month or two in order to take advantage of the new language constructs. These developers will be faced with... install JDT patch... build WTP patch from source... install m2e luna i-build and hope it works with kepler... etc... or maybe just use NetBeans or IntelliJ, both of whom have shipped their Java 8 support already. If we are serious about maintaining a competitive position for Eclipse, we need to do better than telling the users to assemble Java 8 support on their own. - Konstantin -Original Message- From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Doug Schaefer Sent: Sunday, March 23, 2014 12:33 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] Kepler SR3 for Java 8? I would think that if they are advanced enough to jump on Java 8 the minute it releases, they can figure out how to install the Java 8 support into Kepler. Doug. From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Konstantin Komissarchik [konstantin.komissarc...@oracle.com] Sent: Friday, March 21, 2014 11:25 AM To: 'Cross project issues' Subject: Re: [cross-project-issues-dev] Kepler SR3 for Java 8? There have been numerous calls for Java 8 support on the stable Kepler base and patches have been prepared accordingly. This is a discussion of a better way to package and distribute these existing Kepler patches. Many users who do not typically consume Eclipse milestones are not happy with using a Luna milestone for Java 8 support as numerous other areas are in flux and unstable. From this perspective, the proposed J8 release would be significantly more stable in general than M7. - Konstantin -Original Message- From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Ed Willink Sent: Friday, March 21, 2014 8:11 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] Kepler SR3 for Java 8? Hi Surely anyone trying to use Java 8 before June is a bleeding edge user, so what is wrong with M6/M7? Any pretence that a J8 release, sooner than M7, is of higher quality than the M7 release is just misleading. Few projects have used it so there will be numerous serious but often trivial problems to fix. Bug 430875 is the first from me. Regards Ed Willink On 21/03/2014 14:59, Konstantin Komissarchik wrote: Are you talking about separate update site with java 8 patches for kepler or full-blown release? My preference is for a full release. If that doesn't happen, we can discuss an aggregate repo of patches, which doesn't paint Eclipse in the best light, but is somewhat better than many separate repos with patches. In any case, m2e does not plan to participate. Anyone who wants to use m2e with java 8 support on kepler will have to install m2e 1.5 milestone/snapshot build from m2e specific repository. Ok. - Konstantin -Original Message- From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Igor Fedorenko Sent: Friday, March 21, 2014 7:53 AM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Kepler SR3 for Java 8? Are you talking about separate update site with java 8 patches for kepler or full-blown release? In any case, m2e does not plan to participate. Anyone who wants to use m2e with java 8 support on kepler will have to install m2e 1.5 milestone/snapshot build from m2e specific repository. -- Regards, Igor On 2014-03-21
Re: [cross-project-issues-dev] Kepler SR3 for Java 8?
I would think that if they are advanced enough to jump on Java 8 the minute it releases, they can figure out how to install the Java 8 support into Kepler. Doug. From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Konstantin Komissarchik [konstantin.komissarc...@oracle.com] Sent: Friday, March 21, 2014 11:25 AM To: 'Cross project issues' Subject: Re: [cross-project-issues-dev] Kepler SR3 for Java 8? There have been numerous calls for Java 8 support on the stable Kepler base and patches have been prepared accordingly. This is a discussion of a better way to package and distribute these existing Kepler patches. Many users who do not typically consume Eclipse milestones are not happy with using a Luna milestone for Java 8 support as numerous other areas are in flux and unstable. From this perspective, the proposed J8 release would be significantly more stable in general than M7. - Konstantin -Original Message- From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Ed Willink Sent: Friday, March 21, 2014 8:11 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] Kepler SR3 for Java 8? Hi Surely anyone trying to use Java 8 before June is a bleeding edge user, so what is wrong with M6/M7? Any pretence that a J8 release, sooner than M7, is of higher quality than the M7 release is just misleading. Few projects have used it so there will be numerous serious but often trivial problems to fix. Bug 430875 is the first from me. Regards Ed Willink On 21/03/2014 14:59, Konstantin Komissarchik wrote: Are you talking about separate update site with java 8 patches for kepler or full-blown release? My preference is for a full release. If that doesn't happen, we can discuss an aggregate repo of patches, which doesn't paint Eclipse in the best light, but is somewhat better than many separate repos with patches. In any case, m2e does not plan to participate. Anyone who wants to use m2e with java 8 support on kepler will have to install m2e 1.5 milestone/snapshot build from m2e specific repository. Ok. - Konstantin -Original Message- From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Igor Fedorenko Sent: Friday, March 21, 2014 7:53 AM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Kepler SR3 for Java 8? Are you talking about separate update site with java 8 patches for kepler or full-blown release? In any case, m2e does not plan to participate. Anyone who wants to use m2e with java 8 support on kepler will have to install m2e 1.5 milestone/snapshot build from m2e specific repository. -- Regards, Igor On 2014-03-21, 10:44, Konstantin Komissarchik wrote: The issue is that features beyond JDT need to be updated before Java 8 is supported across various Eclipse features. In particular, WTP needs Java 8 facet version before web application developers can take advantage of Java 8. There may be others. In case this goes forward, *could other projects that need to distribute Java 8 enablement signal so on this thread so that we know who would be participating?* - Konstantin *From:*cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] *On Behalf Of *Daniel Megert *Sent:* Friday, March 21, 2014 12:53 AM *To:* Cross project issues *Subject:* Re: [cross-project-issues-dev] Kepler SR3 for Java 8? Hi Konstantin Can you explain why you need two patches? For me the given instructions https://wiki.eclipse.org/JDT/Eclipse_Java_8_Support_For_Keplerwork fine and those involve only one patch / repo. Dani From: Konstantin Komissarchik konstantin.komissarc...@oracle.com mailto:konstantin.komissarc...@oracle.com To: 'Cross project issues' cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org Date: 20.03.2014 15:51 Subject: [cross-project-issues-dev] Kepler SR3 for Java 8? Sent by: cross-project-issues-dev-boun...@eclipse.org mailto:cross-project-issues-dev-boun...@eclipse.org - - -- I am wondering if we should do a limited SR release to pickup Java 8 patches. As it stands, Eclipse users interested in Java 8 would have to hunt for and install at least two patches, which doesn't paint Eclipse in a good light. Thoughts? - Konstantin___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org
Re: [cross-project-issues-dev] Stable URLs for latest Orbit builds
That¹s excellent. Thanks Eike! On 2/13/2014, 5:07 AM, Eike Stepper step...@esc-net.de wrote: Hi all, I find it cumbersome and error-prone that I have to look up the latest Orbit build on http://download.eclipse.org/tools/orbit/downloads modify my various build scripts accordingly before I can kick a build. So I've created a cron job that updates the following p2 composite repos in 5 minute intervals: http://download.eclipse.org/modeling/emf/cdo/orbit/latest-R http://download.eclipse.org/modeling/emf/cdo/orbit/latest-S http://download.eclipse.org/modeling/emf/cdo/orbit/latest-I (currently empty) http://download.eclipse.org/modeling/emf/cdo/orbit/latest-M (currently empty) Each composite contains at most one child repo which is the latest Orbit repo of the respective build type, i.e., R, S, I or M-build. The p2.timestamp of a composite only changes when the child location changes. Please feel free to use these stable URLs yourself if you find them handy ;-) Cheers /Eike http://www.esc-net.de http://thegordian.blogspot.com http://twitter.com/eikestepper P.S.: I'm not a bash expert, so I attach the used bash scripts to this post. Please provide feedback if there's something wrong with them. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Kepler SR2 - Linux - CDT - Problem
That’s very strange. The source CDT repo has the correct linux.x86 iu. Also the correct artifact has been copied over. I have no idea why the content.xml is wrong in the maintenance repo. Doug. From: Markus Knauer mkna...@eclipsesource.commailto:mkna...@eclipsesource.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Wednesday, January 22, 2014 at 9:36 AM To: Jeff Johnston jjohn...@redhat.commailto:jjohn...@redhat.com, Doug Schaefer cdtd...@gmail.commailto:cdtd...@gmail.com, Eclipse Cross Project Issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: [cross-project-issues-dev] Kepler SR2 - Linux - CDT - Problem Hi all, maybe you can help me solving this problem... the EPP build for Kepler SR2 RC1 is broken because of missing dependencies in the maintenance p2 repository. In particular there are some CDT features that require a specific version of Linux bundles. Either something in the CDT contribution is broken, or something from Linuxtools (???) is missing... unit id='org.eclipse.cdt.platform.feature.group' version='8.3.0.201401210350' singleton='false' requires size='29' ... required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.cdt.core.linux.x86' range='[5.2.0.201401210350,5.2.0.201401210350]'... But there's only... unit id='org.eclipse.cdt.core.linux.x86_64' version='5.2.0.201309180223' Maybe it fixes itself later today when all +3 contributions are in... in that case sorry for the noise. My expectation was that this kind of error should have been checked during the aggregation build. Thanks, Markus ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Kepler SR2 - Linux - CDT - Problem
Apologies to all. My e-mails to Eclipse mailing lists got held up the last couple of days for some reason and just got unblocked this morning. I checked the aggregator build and it does seem to have worked. Thanks, Doug From: Markus Knauer mkna...@eclipsesource.commailto:mkna...@eclipsesource.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Thursday, January 23, 2014 at 11:39 AM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Cc: Doug Schaefer cdtd...@gmail.commailto:cdtd...@gmail.com Subject: Re: [cross-project-issues-dev] Kepler SR2 - Linux - CDT - Problem Hi Doug, for some reasons I received your mails just a few minutes ago. The last EPP build finished successfully and I do hope that your change in the CDT composite repository did the trick. Thanks, Markus On Wed, Jan 22, 2014 at 5:25 PM, Doug Schaefer dschae...@qnx.commailto:dschae...@qnx.com wrote: I’ve removed the old versions from the CDT milestones composite. That should force everything to the desired version. The output from the aggregator is showing it’s picking between the two versions somewhat randomly and sometimes both. It could be an upstream dependency that is that is incorrectly depending on the last minor release. We’ll find out when on the next agg build… Doug. From: Doug Schaefer dschae...@qnx.commailto:dschae...@qnx.com Date: Wednesday, January 22, 2014 at 10:38 AM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org, Jeff Johnston jjohn...@redhat.commailto:jjohn...@redhat.com, Doug Schaefer cdtd...@gmail.commailto:cdtd...@gmail.com Subject: Re: [cross-project-issues-dev] Kepler SR2 - Linux - CDT - Problem That’s very strange. The source CDT repo has the correct linux.x86 iu. Also the correct artifact has been copied over. I have no idea why the content.xml is wrong in the maintenance repo. Doug. From: Markus Knauer mkna...@eclipsesource.commailto:mkna...@eclipsesource.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Wednesday, January 22, 2014 at 9:36 AM To: Jeff Johnston jjohn...@redhat.commailto:jjohn...@redhat.com, Doug Schaefer cdtd...@gmail.commailto:cdtd...@gmail.com, Eclipse Cross Project Issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: [cross-project-issues-dev] Kepler SR2 - Linux - CDT - Problem Hi all, maybe you can help me solving this problem... the EPP build for Kepler SR2 RC1 is broken because of missing dependencies in the maintenance p2 repository. In particular there are some CDT features that require a specific version of Linux bundles. Either something in the CDT contribution is broken, or something from Linuxtools (???) is missing... unit id='org.eclipse.cdt.platform.feature.group' version='8.3.0.201401210350' singleton='false' requires size='29' ... required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.cdt.core.linux.x86' range='[5.2.0.201401210350,5.2.0.201401210350]'... But there's only... unit id='org.eclipse.cdt.core.linux.x86_64' version='5.2.0.201309180223' Maybe it fixes itself later today when all +3 contributions are in... in that case sorry for the noise. My expectation was that this kind of error should have been checked during the aggregation build. Thanks, Markus ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Did the signing process break ... on 12/18?!
Yikes indeed. I’ll double check CDT’s to see what happened. Doug. From: David M Williams david_willi...@us.ibm.commailto:david_willi...@us.ibm.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Wednesday, January 15, 2014 at 12:01 AM To: cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: [cross-project-issues-dev] Did the signing process break ... on 12/18?! I just happened to notice there were over three hundred unsigned jars in Luna aggregations ... http://build.eclipse.org/simrel/luna/reporeports/reports/verifydiroutput/unsigned.txt Normally there are 20 or 40. In particular I noticed many are from projects that normally have excellent releng records, and, further, judging from the qualifier, appeared many of those were built on December 18th. If this was a releng mis-step, then no big deal ... plenty of time to get it fixed up ... but, I thought I would point it out, since, from my experience, there are time's that once a jar is in a repo unsigned (due to what ever reason, but especially if due to a 'glitch'), then the bundle has to be touched so its qualifier increases, so the now new, working signed version gets updated to the repo. Whether or not this is true for the projects in question depends on details of their builds, which I have no knowledge of. I was just so surprised to see so many, thought I'd point it out. And, by the way, signing seems to be working fine now ... this is just a question of about why so many are unsigned, many of which were built on the same day, apparently. Thanks, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] [epp-dev] m2e ponders participation in luna
I'm not sure our +123 system works well enough anymore. The deps are more than four deep. We should really graph them out. Sent from my BlackBerry Z30 smartphone. Original Message From: Igor Fedorenko Sent: Wednesday, December 18, 2013 3:07 PM To: cross-project-issues-dev@eclipse.org Reply To: Cross project issues Subject: Re: [cross-project-issues-dev] [epp-dev] m2e ponders participation in luna +2 is fine. Ideally, m2e should go after platform and xml editor (not sure where this comes from now), but in practice we always build against previous milestone and usually have our builds ready in advance. -- Regards, Igor On 12/18/2013, 15:04, Wayne Beaton wrote: How do you feel wrt +2 or +3 (in consideration of m2e-wtp)? Wayne On 12/18/2013 03:02 PM, Igor Fedorenko wrote: I created release record. You can find release plan.xml in our site git repository http://git.eclipse.org/c/www.eclipse.org/m2e.git/tree/plan.xml?id=6c18b3cf58143f5f462f2f3b601ef2996887ef07 -- Regards, Igor On 12/18/2013, 14:10, Wayne Beaton wrote: You need to create a release record that I can reference. That release record needs to include plan information. http://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#State_intent_early_.28M4.29 Wayne On 12/18/2013 07:23 AM, Igor Fedorenko wrote: @Wayne please update your records that m2e will participate in luna, offset is +3, but does not really matter -- Wayne Beaton Director of Open Source Projects, The Eclipse Foundation http://www.eclipse.org Learn about Eclipse Projects http://www.eclipse.org/projects EclipseCon 2014 http://www.eclipsecon.org/na2014 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Wayne Beaton Director of Open Source Projects, The Eclipse Foundation http://www.eclipse.org Learn about Eclipse Projects http://www.eclipse.org/projects EclipseCon 2014 http://www.eclipsecon.org/na2014 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Release train broken for MacOS?
As a Mac user, I prefer the bundled package. I can then place my
Eclipse.app into my /Applications folder and it can look like any other
Mac app that I put there.
Doug.
On 12/10/2013, 1:52 AM, Eike Stepper step...@esc-net.de wrote:
Thank you for the infos. I've found the code that causes my trouble. It's
in DirectorApplication.initializeProfile():
if
(org.eclipse.osgi.service.environment.Constants.OS_MACOSX.equals(os)
destination.getName().endsWith(.app))
{
env += ',' +
org.eclipse.equinox.p2.core.spi.Constants.MACOSX_BUNDLED + =true;
//$NON-NLS-1$
}
That implies (and I've tested) that the problem goes away if the
destination does *not* end with .app. I'm not a Mac
user myself and I have no clue what the consequences are when I leave the
.app out. Does it impact the way the
application is / can be started? Pascal told me that the cool Mac users
install into *.app folders because that would
flatten out the nested Profile.app folder somehow, which is true in my
cross-platform Hudson build for an RCP product.
But I found that the Eclipse SDK always appears with a nested Eclipse.app
folder, whether the root folder ends with
.app or not.
Fails: director -repository http://download.eclipse.org/releases/luna;
-installIU org.eclipse.sdk.ide
-profileProperties org.eclipse.update.install.features=true -p2.os
macosx -p2.ws cocoa -p2.arch x86_64 -destination
*Eclipse.app*
Works: director -repository http://download.eclipse.org/releases/luna;
-installIU org.eclipse.sdk.ide
-profileProperties org.eclipse.update.install.features=true -p2.os
macosx -p2.ws cocoa -p2.arch x86_64 -destination
*Eclipse*
Cheers
/Eike
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 09.12.2013 16:07, schrieb David M Williams:
Is someone actively working on a fix?
It's hard to speak for everyone, but I am not. Contributions welcome.
To summarize my understanding of the issue (which is easily the wrong
understanding) is that p2 introduced this new IU
filter (macosx-bundled) that should be transparent to everyone; that
we (in Platform, and Sim. Release repo) do not
want this phantom IU filter; we have no plans to support or provide
it; and most important, I do not know how to get
rid if it. (There's some vague suggestion that every time a repo is
mirrored it has to be filtered out ... but I
don't really know what that means or why we should have to if
transparent to everyone.)
You don't say ... are you trying to make use of the macosx-bundled
filter? Or the legacy layout? If the former, I
think you can't ... if the latter, you may be able to refine your
filter statement.
Again, contributions welcome, and bug 407588 is likely best place to
discuss the issues.
Thanks,
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Release train broken for MacOS?
Been through this hell :). The typical p2 mirror type operations usually operate without macosx-bundled being defined so the required IU falls off. Not sure how to fix it. Doug. On 12/9/2013, 7:09 AM, Eike Stepper step...@esc-net.de wrote: Hi, I'm trying to install org.eclipse.sdk.ide with the p2 director application onto a Mac and it fails miserably with this message: org.eclipse.core.runtime.CoreException: Cannot complete the install because one or more required items could not be found. at org.eclipse.equinox.internal.p2.director.app.DirectorApplication.planAndEx ecute(DirectorApplication.java:775) at org.eclipse.equinox.internal.p2.director.app.DirectorApplication.performPr ovisioningActions(DirectorApplication.java:763) [...] Contains: Software being installed: Eclipse SDK 4.4.0.I20130918-2000 (org.eclipse.sdk.ide 4.4.0.I20130918-2000) Contains: Missing requirement for filter properties ~= $0: toolingorg.eclipse.sdk.ide.application 4.4.0.I20130918-2000 requires 'toolingorg.eclipse.sdk.ide.executable.cocoa.macosx.x86_64-bundled [4.4.0.I20130918-2000]' but it could not be found Contains: Cannot satisfy dependency: Contains: From: Eclipse SDK 4.4.0.I20130918-2000 (org.eclipse.sdk.ide 4.4.0.I20130918-2000) Contains: To: toolingorg.eclipse.sdk.ide.application [4.4.0.I20130918-2000] So, I've looked at Luna's content.xml and found this requirement: required namespace='org.eclipse.equinox.p2.iu' name='toolingorg.eclipse.sdk.ide.executable.cocoa.macosx.x86_64-bundled' range='[4.4.0.I20130918-2000,4.4.0.I20130918-2000]' filter (amp;(macosx-bundled=true)(osgi.arch=x86_64)(osgi.os=macosx)(osgi.ws=coco a)) /filter /required Which indeed does not exist. Google brought up a number of bugs tat might be related: https://bugs.eclipse.org/bugs/show_bug.cgi?id=408268 (David's comment #7 seems related, but the bug is closed) https://bugs.eclipse.org/bugs/show_bug.cgi?id=408581 https://bugs.eclipse.org/bugs/show_bug.cgi?id=407588 https://bugs.eclipse.org/bugs/show_bug.cgi?id=394216 Is it possible that the release train repos are so badly broken / inconsistent? Is someone actively working on a fix? Are there workarounds possible? Cheers /Eike http://www.esc-net.de http://thegordian.blogspot.com http://twitter.com/eikestepper ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Freemarker
Well, I'm running the resultant generated code through the code formatter so spacing isn't as big an issue for me. Having an easy API does matter, especially ones that can pull the template out of the bundle without resorting to the FileLocator. I have a dead simple template engine now that just does variable substitution. I'll take a look at Xtend and see if it meets our needs. Thanks! Doug. From: Sven Efftinge sven.effti...@itemis.demailto:sven.effti...@itemis.de Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Tuesday, 22 October, 2013 12:50 PM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Freemarker Yes, it is sort of a Java extension. For instance it extends Java with support for template string concatenation ;-) The advantage of Xtend over Freemarker and the like is that it is statically typed and has very good tool support. In addition it sports smart whitespace handling. I've recorded a screencast some time ago, demoing the template support: https://vimeo.com/20734786 Sven On Oct 22, 2013, at 3:50 PM, Doug Schaefer dschae...@qnx.commailto:dschae...@qnx.com wrote: Xtend is a Java language extension, no? I'm talking about a template engine that we use in the new project wizard to instantiate code templates based on various user selectable options. I was originally thinking of Jet, but I can't seem to find it anymore. Whatever happened to it? Doug. From: Henrik Rentz-Reichert h...@protos.demailto:h...@protos.de Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Tuesday, 22 October, 2013 2:43 AM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Freemarker Doug, have you considered using Xtend? -Henrik Am 21.10.2013 21:47, schrieb Doug Schaefer: Has anyone tried to get Freemarker into Orbit? Or is there a better template engine that people are using. CDT has it's own but I'd like to use something more standard (and better). Thanks, Doug. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.orghttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Freemarker
Has anyone tried to get Freemarker into Orbit? Or is there a better template engine that people are using. CDT has it's own but I'd like to use something more standard (and better). Thanks, Doug. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Nightly/weekly builds of Kepler SR-2
Hey gang, As I try to get our Momentics builds closer to the bleeding edge, I'm wondering if we have nightly builds of Kepler SR-2 simrel repo on the go. I know we talked quickly about that but now I have a burning need. Thanks, Doug. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit
Three words: Fetch from Gerrit…. Can't beat that for downloading a change and trying it out. From: John Arthorne john_artho...@ca.ibm.commailto:john_artho...@ca.ibm.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Monday, 7 October, 2013 9:51 AM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit Doug Schaefer dschae...@qnx.commailto:dschae...@qnx.com wrote on 10/04/2013 06:47:08 PM: No they're not. I can't see any way that patches in bugzilla are easier than gerrit. It's one Push to Gerrit and one Publish and Submit clicks away from getting a contribution made and accepted. The Submit button is a bit dangerous that way. For most changes you can't thoroughly review it without trying it out, which means loading it into your local workspace. For a bugzilla patch you can paste it directly into the navigator so it really can't be beat (about four keystrokes for the whole process to copy/paste the patch). Whether you use UI or command line, Gerrit is a bit more work there. But really which is mechanically easier is not the point with Gerrit. By creating a branch for each change, Gerrit is setting up a much richer structure that will naturally be a bit more work but also much more powerful. Gerrit really shines on big changes that take several iterations. For example comparing the latest patch against either master or any previous draft is very easy to do in Gerrit, and very difficult with patch files. Being able to flag each file as reviewed so you can later come back to it is also really nice. And to me the most powerful feature is the ability to rebase the patch directly from within Gerrit, which makes it very easy to keep patches in sync with master, unlike bugzilla patches that tend to rot quickly and usually the contributor is asked to do the rebasing. So my advice would be, even if Gerrit feels like more work for you because you have mastered your old bugzilla patch workflow, it's worth giving it a try. With email notifications and a handy dashboard it really isn't more work to monitor and accept contributions on both channels. I really don't think Gerrit needs to be forced on projects though if they aren't seeing the benefit yet. John ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit
I almost wonder if we should just enable Gerrit for all projects. That's what we do internally here for all git repos that feed into product. It's great for all the reasons you mention Ed. The thing I like most about it is the verification jobs in co-ordination with Hudson. You have so much more confidence when a change request is sitting there knowing it has passed the JUnit run. I'm going to set that up for CDT ASAP now that we have a HIPP instance. Doug. From: Ed Merks ed.me...@gmail.commailto:ed.me...@gmail.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Friday, 4 October, 2013 2:34 AM To: cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Making your project more open…howto enable Gerrit Miles, If found migration to gerrit for EMF to be yet another painful step with the migration from CVS to (E)git being the first one. So incredibly many magical settings and so many fundamentally important new concepts. In the end though, I can definitely say that the pain is worth the gain. If you're even a little bit serious about opening up your project up to external contribution and really expect it to happen, you're missing the boat if you don't migrate to gerrit, which makes it incredibly simple for anyone to develop a contribution, i.e., anyone in the community can actually commit the changes in their local clone back to your Eclipse gerrit clone, which can be configured to run your build and run all your tests to confirm that the contribution doesn't break the build or tests, and then you can simply review and accept the contribution and by doing so, commit it into your real git repo. Of course gerrit is useful even just for the committers of a project, allowing you to run a build and the tests before you commit back to the real git repo, and naturally you can then do reviews easily and can run further test the patches locally (once you learn more of the git magic for how that works and don't shoot your own foot off in the process). On 03/10/2013 8:19 PM, Miles Parker wrote: Project leads: I just tweeted about my disappointment in how many projects have not yet enabled Gerrit. Chris A. pointed out that it wouldn't be a bad thing to send a reminder to x-platform . All joking aside[http://milesparker.blogspot.ca/2013/01/adopting-gerrit.html] it really isn't hard, just click here!! https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Communitycomponent=Gerritshort_desc=Enable%20Gerrit%20for%20my%20project cheers, Miles Miles T. Parker | Tasktop Labs | Tasktop Technologies email: miles.par...@tasktop.commailto:miles.par...@tasktop.com web: http://tasktop.com | blog: http://milesparker.blogspot.com Committer: Eclipse Mylyn Reviews, R4E, Virgo Lead: Eclipse Mylyn MFT, AMP Are you passionate about innovation and excellence and interested in joining our team? Tasktop, voted one of the Best Companies to Work for in British Columbia, is hiring! ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.orghttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit
No they're not. I can't see any way that patches in bugzilla are easier than gerrit. It's one Push to Gerrit and one Publish and Submit clicks away from getting a contribution made and accepted. And can't help wonder that these two statements aren't related in some way: m2e has no plans to accept gerrit contributions We have extremely low level of contributions. On 2013-10-04 1:54 PM, Igor Fedorenko i...@ifedorenko.com wrote: Yes. Patches attached to bugzilla are easier. -- Regards, Igor On 2013-10-04 12:25 PM, Mickael Istria wrote: On 10/04/2013 06:08 PM, Igor Fedorenko wrote: m2e has no plans to accept gerrit contributions, at least not for now. I'm curious: Why is this so? Did you find a process that makes contributing easier than it is by Gerrit? -- Mickael Istria Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools My blog http://mickaelistria.wordpress.com - My Tweets http://twitter.com/mickaelistria ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit
Yes, that generally how we work too. We're big users of Gerrit internally here on Momentics. That's generally how things go. Discussions happen in our bug system (JIRA), but only comments on the code happen in Gerrit. In all the bugzilla's I've looked at over the years, there actually weren't that many detailed code discussions there anyway. Gerrit lets you attach comments right to the lines. Bugzilla has never claimed to be a code review tool. BTW, great to hear that about SWTbot. You can't help but think making contribution and review easier is healthy for a project. Doug. From: Mickael Istria mist...@redhat.commailto:mist...@redhat.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Friday, 4 October, 2013 5:24 PM To: cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit On 10/04/2013 09:00 PM, Ian Bull wrote: I'm not sure how the more experienced Gerrit users deal with this. I don't consider myself as an expert, but I generally try to keep discussion related to use-case, test scenario and possible designs on the Bugzilla, and put discussions about code itself of Gerrit as it allows inline comments in contributions, versioning and comparison of patches, easy fetch, automatic CI check. When the discussion on Bugzilla has come to a point where it becomes possible to write code, I put a link to a Gerrit contrib on Bugzilla. Then most of the discussion happens on the Gerrit patch, and when it is done, it gets merged and then we can close the Bugzilla entry.a Bugzilla tracks ideas, Gerrit tracks code changes. Not sure it's optimal, but I find it more comfortable than dealing with patches to merge and test, mark obsolete and put comments without a scope in Bugzilla. I also think it makes it easier to review a contribution when we see it does not introduce regression before even we look at the code. And I also find it easy for a contributor to learn to take care about regression tests when pushing a change on Gerrit: if he broke something, a mail automatically warns the contributor. It tends to give more sense of responsibility and then to provide better quality in patches. SWTBot enabled Gerrit last year. Since then, project had 8 new contributors; for a total of 20 contributors in 5 years of existence. I'm not sure it is directly related, but I do feel Gerrit has been helpful to increase project activity, diversity and openness. My 2c. -- Mickael Istria Eclipse developer at JBoss, by Red Hathttp://www.jboss.org/tools My bloghttp://mickaelistria.wordpress.com - My Tweetshttp://twitter.com/mickaelistria ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Installing B3 WindowBuilder
I get the same thing. So I gave up and made the changes directly to the files using the text editor. Not good by any means. From: Mark Russell mrruss...@google.commailto:mrruss...@google.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Tuesday, 17 September, 2013 11:42 AM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: [cross-project-issues-dev] Installing B3 WindowBuilder I have a new machine since my last aggregation build for WindowBuilder. I'm following http://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build to set up the simrel B3 Aggregation. Everytime I try to install B3 I get this error: Cannot complete the install because one or more required items could not be found. Software being installed: b3 Aggregator Editor (Incubation) 0.2.0.v20130827-2305 (org.eclipse.b3.aggregator.editor.feature.feature.group 0.2.0.v20130827-2305) Missing requirement: EMF Edit UI 2.9.0.v20130819-1254 (org.eclipse.emf.edit.ui 2.9.0.v20130819-1254) requires 'bundle org.eclipse.emf.common.ui [2.8.0,3.0.0)' but it could not be found Cannot satisfy dependency: From: b3 Aggregator Editor (Incubation) 0.2.0.v2022-1524 (org.eclipse.b3.aggregator.editor 0.2.0.v2022-1524) To: bundle org.eclipse.emf.edit.ui [2.9.0,3.0.0) Cannot satisfy dependency: From: b3 Aggregator Editor (Incubation) 0.2.0.v20130827-2305 (org.eclipse.b3.aggregator.editor.feature.feature.group 0.2.0.v20130827-2305) To: org.eclipse.b3.aggregator.editor [0.2.0.v2022-1524] I have a new version of eclipse 4.2.2 and I have installed eGit and loaded the Repo. Any help would be great :-) -- Mark R Russell (724) 473-3140 Software Engineer in Test Catalogs Team Google Pittsburgh ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] CDT in Luna
CDT will be participating in the Luna simrel. Offset is kinda +1 although we have a tiny bit that depends on RSE but it seems to work out in the end. Now to be weird, we are releasing CDT 8.3 with Kepler SR-2 but it will also appear on Luna milestones. We will then transition to CDT 8.4 for the final Luna release. Plans are here: https://projects.eclipse.org/projects/tools.cdt/releases/8.3.0 https://projects.eclipse.org/projects/tools.cdt/releases/8.4.0 Mind you we probably won't know the 8.4 plan until near the end of 8.3. And we don't really have an 8.3 plan yet. We are transitioning to release a minor release every SR starting with the 8.3 release. Doug. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Has Java 5 Platform support been discontinued?
I think you dodged the answer :). If you use Java 5, you're have no guarantees. We could change org.eclipse.* to 1.6, but that would be a huge effort for little gain. From: Ed Willink e...@willink.me.ukmailto:e...@willink.me.uk Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Tuesday, 3 September, 2013 10:45 AM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Has Java 5 Platform support been discontinued? Hi I'm sorry John but you are dodging the issue. There is far too much this is what we do, and very little of this is what we require. Most of the Eclipse SDK is pure Java code and has no direct dependence on the underlying operating system. The chief dependence is therefore on the Java Platform itself. Portions are targeted to specific classes of operating environments, requiring their source code to only reference facilities available in particular class libraries (e.g. J2ME Foundation 1.1, J2SE 1.4, Java 5, etc). In general, the 4.3 release of the Eclipse Project is developed on a mix of Java SE 6 and Java SE 7 VMs. As such, the Eclipse SDK as a whole is targeted at all modern, desktop Java VMs. Most functionality is available for Java SE 6 level development everywhere, and extended development capabilities are made available on the VMs that support them. Yes there have been a few bundles that needed 1.6 for some time, but it seems like the critical parts of the platform have been 1.5. The list on http://www.eclipse.org/projects/project-plan.php?projectid=eclipse#appendix still shows very little that needs 1.6, so I see no statement that the platform needs 1.6. I delivered my Indigo, Juno and Kepler releases as Java 5 minimum requirement. Clearly the platform and many projects were highly Java 5 tolerant. There should perhaps be a separate overall statement at the top that 1.6 is the minimum requirement (although some bundles may be more tolerant). Or org.eclipse.core.* needs to change to 1.6 Regards Ed Willink On 03/09/2013 14:57, John Arthorne wrote: I seem to have a knack for definitive statements lately so I'll take a try at this. The last Eclipse Platform release to officially support Java 5 was 3.6/Helios. We have not run our tests against Java 5 for several years and can make no claim that it works. Since Platform 3.8 it has certainly been impossible to run the complete platform using Java 5 due to Jetty dependency on Java 6 (and possibly other bundles). Oracle Java end of life was in 2009 (in fact Oracle Java 6 is also past end of life now). Some individual bundles may still support older runtimes but at this point they are the exception rather than the norm. The list of bundle EE levels is updated with each plan revision, but as long as they are within the scope of the current list of reference platforms they are not generally announced individually. John From:Ed Willink e...@willink.me.ukmailto:e...@willink.me.uk To:Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org, Date:09/03/2013 09:24 AM Subject:Re: [cross-project-issues-dev] Has Java 5Platform supportbeendiscontinued? Sent by: cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org Hi I am doing my best to continue support for existing functionality, so in the absence of a clear Eclipse statement that Java 5 support is terminated, I feel I have to continue to keep close to 5. Guava changing to Java 6 was awkward. OSGI changing to Java 6 is very close to a mandatory downstream consequence. Can we please have a clear policy statement rather than a secretive creep. I don't mind changing to Java 6, it probably makes life easier. But I hate this are we 5 or 6 limbo? Regards Ed Willink On 03/09/2013 13:51, David M Williams wrote: I probably should have mentioned, there are several bugs we are still trying to work through, where the Tycho/Maven build picks a different compiler level than the way PDE used to it ... and not always in the way we intend, for example, https://bugs.eclipse.org/bugs/show_bug.cgi?id=415116 https://bugs.eclipse.org/bugs/show_bug.cgi?id=411419 I am not sure if this is related to the issue you are seeing ... or if merely confirms yet another unannounced change ... but I don't think it changes the bottom line: If you want things different than they are, open a bug or comment on an existing one. If it is merely a matter that you don't really care, but you have to change your test scripts, then all I can say is sorry. From:Ed Willink e...@willink.me.ukmailto:e...@willink.me.uk To:Cross project issues
Re: [cross-project-issues-dev] Status and Outlook for Luna M1
+1 This causes more pain on the community than it solves. Mind you I said that last year too. At the end of the day, I pushed our last kepler build into Luna M1, which is what would have happened by default. Sent from my BlackBerry 10 smartphone on the Rogers network. From: Laurent Goubet Sent: Monday, September 2, 2013 10:35 AM To: cross-project-issues-dev@eclipse.org Reply To: laurent.gou...@obeo.fr Subject: Re: [cross-project-issues-dev] Status and Outlook for Luna M1 Disabling all projects every year will always cause such issues : the Acceleo team was in holidays for most of August, which makes us miss M1. The same goes for ATL. Per change, we had one of the EMF Compare Team at hand to activate that one contribution (and even still, he had to tweak our build to manually remove features for which our dependencies are also marked as disabled). I think that leaving the contributions enabled would be better than forcing everyone into this situation : we have to load the aggregator, enable our contribution, check if it works... and come back at regular intervals to check for our dependencies' enablement. This is time consuming for those of us who depend on a few projects... and frustrating since we know that we are in turn blocking others. Not to mention that this always comes at a time where most of us are in holidays and just cannot react. I think this had already been discussed last year, and I do not know if leaving all projects enabled by default is better, at least it would not block anything. Grégoire, Acceleo will be enabled some time tomorrow (CEST), sorry for the wait. Laurent Goubet Obeo On 22/08/2013 18:11, Grégoire Dupé wrote: Hello I'm still waiting for Acceleo and ATL (may be more) to deliver MoDisco. It's quite late in Europe; I've to leave the office. I assume that MoDisco will not be included in Luna M1 :-( Regards, Grégoire - Original Message - From: David M Williams david_willi...@us.ibm.com To: cross-project-issues-dev@eclipse.org Sent: Jeudi 22 Août 2013 10:13:05 Subject: [cross-project-issues-dev] Status and Outlook for Luna M1 Ok, it's Thursday morning :) Only a few more have been enabled, but that includes DTP and BIRT, so that should help Luna (Kepler RC1 repo is already considered done). That allowed me to enabled the JPA portions of WTP (since depends on DataTools) which, I noticed, some others depended on, but I had to leave WTPs JPA Diagram Editor disabled, since it depends on Graphiti, which is not enabled yet. Which brings me to my main point. Scanning the list of 22 disabled contributions, I'd guess about half are leaf components, so if you don't get enabled, it'd hurt no one but your self ... and maybe community and adopters? But, I'd guess, the other half such as graphiti, gmf? a few emf ones? and DLTK are definitely building blocks that need to be enabled or else others downstream can not function or be enabled. If you are a consuming project and need some of those lower level ones enabled, I'd encourage a lot of project-to-project communication so they know how much you depend on them, and the effect they have by being late or incomplete, etc. So, I'm just asking everyone to be aware of your place in the eco system and plan accordingly. I suspect I'm just stating the obvious ... but not sure what else I can do to help. Thanks, = = = = = = = = = actf.b3aggrcon - org.eclipse.simrel.build amalgam.b3aggrcon - org.eclipse.simrel.build amp.b3aggrcon - org.eclipse.simrel.build dltk.b3aggrcon - org.eclipse.simrel.build ecf.b3aggrcon - org.eclipse.simrel.build emf-compare.b3aggrcon - org.eclipse.simrel.build emft-ecoretools.b3aggrcon - org.eclipse.simrel.build emft-eef.b3aggrcon - org.eclipse.simrel.build emft-egf.b3aggrcon - org.eclipse.simrel.build gmp-gmf-tooling.b3aggrcon - org.eclipse.simrel.build gmp-graphiti.b3aggrcon - org.eclipse.simrel.build jwt.b3aggrcon - org.eclipse.simrel.build koneki.b3aggrcon - org.eclipse.simrel.build m2m-atl.b3aggrcon - org.eclipse.simrel.build m2t-acceleo.b3aggrcon - org.eclipse.simrel.build mdt-modisco.b3aggrcon - org.eclipse.simrel.build mft.b3aggrcon - org.eclipse.simrel.build mylyn-docs-intent.b3aggrcon - org.eclipse.simrel.build pdt.b3aggrcon - org.eclipse.simrel.build soa-bpel.b3aggrcon - org.eclipse.simrel.build soa-sca.b3aggrcon - org.eclipse.simrel.build windowbuilder.b3aggrcon - org.eclipse.simrel.build ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org
Re: [cross-project-issues-dev] JFace Generics
Clearly this is a very sensitive issue. It's probably going to take us years to get over our history. And as an open community, we're not always going to agree. But let's keep the discussion technical. I think that'll really help move us forward. And to that end, I think Ed Merks raises a great point about whether this change really helps us in the end. Doing it in a topic branch will definitely get us that information as we try to use the new APIs in an experimental fashion. Doug. From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Eike Stepper [step...@esc-net.de] Sent: Friday, August 30, 2013 6:38 AM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] JFace Generics Am 30.08.2013 12:09, schrieb Mickael Istria: IMO, it's fine to expect feedback such from community. Isn't it what a community is about, working together on the same thing ? ;) I think I've clearly expressed at what quality stage I expect the overall community to be involved. Also, we have to admit that this early push did work like a charm Yes, if the goal was to foster the I hate Eclipse mentality. and generated a lot of useful feedback which will strengthen the implementation of JFace generics, in such a early stage of the release stream. The same effect could (should!) have easily been achieved by actually *using* the new APIs in the platform. So, as a retrospective, it appears To you... that committing this change early was actually a very smart move :P I'm speechless! Cheers /Eike http://www.esc-net.de http://thegordian.blogspot.com http://twitter.com/eikestepper ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Status and outlook for Luna M1
I've re-enabled CDT. Sorry for wasting the time of the person who put enabled=false into our file. Doug. From: Sergey Boyko serg.boyko2...@gmail.commailto:serg.boyko2...@gmail.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Wednesday, 21 August, 2013 10:18 AM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Status and outlook for Luna M1 QVTo was re-enabled for Luna. Cheers... Sergey On Wed, Aug 21, 2013 at 8:00 AM, David M Williams david_willi...@us.ibm.commailto:david_willi...@us.ibm.com wrote: Doesn't look good. I'll admit there is one day left, but so far 50 projects have not even enabled their contribution to Luna (pasted below). ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Status and outlook for Luna M1
Sigh. RSE isn't enabled so CDT fails. From: Doug Schaefer dschae...@qnx.commailto:dschae...@qnx.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Wednesday, 21 August, 2013 10:49 AM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Status and outlook for Luna M1 I've re-enabled CDT. Sorry for wasting the time of the person who put enabled=false into our file. Doug. From: Sergey Boyko serg.boyko2...@gmail.commailto:serg.boyko2...@gmail.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Wednesday, 21 August, 2013 10:18 AM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Status and outlook for Luna M1 QVTo was re-enabled for Luna. Cheers... Sergey On Wed, Aug 21, 2013 at 8:00 AM, David M Williams david_willi...@us.ibm.commailto:david_willi...@us.ibm.com wrote: Doesn't look good. I'll admit there is one day left, but so far 50 projects have not even enabled their contribution to Luna (pasted below). ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Status and outlook for Luna M1
Not to join would be a disservice to the community. Glad you allow us in. :) Sent from my BlackBerry 10 smartphone on the Rogers network. From: David M Williams Sent: Wednesday, August 21, 2013 2:54 PM To: Cross project issues Reply To: Cross project issues Subject: Re: [cross-project-issues-dev] Status and outlook for Luna M1 I've enabled most of WTP (and yes, Carl asked me specifically to cover for him :) ... I enabled all the pieces that do not depend on DTP (e.g. JPA) ... so that should get us a little further. My local validation worked in editor and we'll see how the Hudson aggregation goes. Unfortunately -- from the poking around I've done -- DTP (and BIRT) likely won't be enabled/updated until 7 or 8 Eastern time at the earliest ... due to timezone differences ... so a) don't worry about getting lots of failures the rest of the day ... I know all the email build break reminders drives people crazy. But, b) we will still try to have a relatively complete repo for M1 but not sure there will be time to do EPP packages ... but ... I am forever optimistic -- believe it or not. We are currently down to 27 (from yesterday's 50) projects that have not enabled their contribution. (List below) Unfortunately many of those (like DTP) are depended on by many others so I remind you low level projects you are holding up others! @Igor, and others, the advantage to enabling contribution even if you leave repo disabled due to missing pre-reqs is just a matter of helping me (and others) track the current state and likelihood of making the goal. If, by Thursday morning, there are still, say 20, who have not even bothered to enable contribution, I'd be prone to conclude no way. Whereas if all contributions were enabled, and just some features were not yet fitting together, I might be more optimistic it could be worked out by end of Thursday. [Since you asked why bother.] @Doug, and others ... no problem at all for me to set enabled=false ... and, you know, I can never tell about CDT -- if they'll be the release or not ... glad you decided to join! :) = = = = = actf.b3aggrcon - org.eclipse.simrel.build amalgam.b3aggrcon - org.eclipse.simrel.build amp.b3aggrcon - org.eclipse.simrel.build birt.b3aggrcon - org.eclipse.simrel.build dltk.b3aggrcon - org.eclipse.simrel.build dtp.b3aggrcon - org.eclipse.simrel.build ecf.b3aggrcon - org.eclipse.simrel.build emf-compare.b3aggrcon - org.eclipse.simrel.build emft-ecoretools.b3aggrcon - org.eclipse.simrel.build emft-eef.b3aggrcon - org.eclipse.simrel.build emft-egf.b3aggrcon - org.eclipse.simrel.build epp-mpc.b3aggrcon - org.eclipse.simrel.build gmp-gmf-tooling.b3aggrcon - org.eclipse.simrel.build gmp-graphiti.b3aggrcon - org.eclipse.simrel.build jwt.b3aggrcon - org.eclipse.simrel.build koneki.b3aggrcon - org.eclipse.simrel.build m2e-wtp.b3aggrcon - org.eclipse.simrel.build m2e.b3aggrcon - org.eclipse.simrel.build m2m-atl.b3aggrcon - org.eclipse.simrel.build m2t-acceleo.b3aggrcon - org.eclipse.simrel.build mdt-modisco.b3aggrcon - org.eclipse.simrel.build mft.b3aggrcon - org.eclipse.simrel.build mylyn-docs-intent.b3aggrcon - org.eclipse.simrel.build pdt.b3aggrcon - org.eclipse.simrel.build soa-bpel.b3aggrcon - org.eclipse.simrel.build soa-sca.b3aggrcon - org.eclipse.simrel.build windowbuilder.b3aggrcon - org.eclipse.simrel.build From:Konstantin Komissarchik konstantin.komissarc...@oracle.com To:'Cross project issues' cross-project-issues-dev@eclipse.org, Date:08/21/2013 02:29 PM Subject:Re: [cross-project-issues-dev] Status and outlook for Luna M1 Sent by:cross-project-issues-dev-boun...@eclipse.org Sapphire contribution is waiting on WTP contribution, which is waiting on DTP contribution. Disabling higher-level contributions until all the dependencies have been contributed is one option, but creates a lot of churn and forces a linear contribution path that guarantees that M1 repo is going to be quite thin. If WTP is still not contributed by the end of the day, I will disable Sapphire, but I am not sure how many EPP packages can be created from a repository in such a state… - Konstantin From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Oberhuber, Martin Sent: Wednesday, August 21, 2013 10:36 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] Status and outlook for Luna M1 I have “declared intent” for tcf-1.2 by enabling the contribution … but will keep the repo disabled until the build is green. The build has been failing since 11.01am server time today so I’m not sure if it’s a good idea adding more contributions before it is green … in the end, someone (David?) would need to disable culprits. FWIW, when running the “validate aggregation” in the b3 model editor I get this error right now: Cannot complete the install because one or more required items could not be
Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository
BTW, as I work through my maven/tycho prototype for the aggregator, it doesn't seem that far fetched that would could have nightly aggregator builds. Not sure why we couldn't have that now mind you. BTW2, I fear the Nexus. But that's probably just me and my lack of education on it. I know how to manage my p2 repos. Doug. From: Matthias Sohn matthias.s...@gmail.commailto:matthias.s...@gmail.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Wednesday, 21 August, 2013 3:47 PM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository On Wed, Aug 21, 2013 at 7:45 PM, Igor Fedorenko ifedore...@sonatype.commailto:ifedore...@sonatype.com wrote: Again, I am not arguing against building with individual dependency repositories. All I am saying there is currently no convenient way to do this and I don't have the timeresources to maintain such fine-grained dependency configuration. I am particularly concerned about two problems. First, I need to find location of proper dependency versions to build for luna, kepler and juno (we have N-1 compatibility policy). Second, I need a way to know if these dependency repositories go stale and need to be updated. One way to address these is to require each participating project provide separate repository URL they recommend for use as build target for each yearly release and make list of these URLs documented somewhere. maybe it would help if we would ask all projects to deploy their snapshots/milestones/releases into Nexus (repo.eclipse.orghttp://repo.eclipse.org). This would simplify finding all these p2 repositories in a central place. -- Matthias ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Question on Kepler SR1 release review
Yeah actually that doesn't make sense. Why have the release sit around for a month instead of fixing bugs in it right to the end of the SR? Sent from my BlackBerry 10 smartphone on the Rogers network. From: Igor Fedorenko Sent: Wednesday, August 14, 2013 11:24 AM To: cross-project-issues-dev@eclipse.org Reply To: Cross project issues Subject: Re: [cross-project-issues-dev] Question on Kepler SR1 release review Is new releases must be released a month before SR RC1 a new requirement? -- Regards, Igor On 2013-08-14 6:53 PM, David M Williams wrote: I'll take this topic as a good segue to summarize Planning Council's view on more frequent releases and including new features in SRs. I'll try to keep in brief, but anyone is welcome to read my full notes of meeting at http://wiki.eclipse.org/Planning_Council/August_7_2013 First, it was recognized our slow pace was not satisfying all projects and adopters, but ... Second, it was satisfying most, so the short answer is status quo continues ... though we committed to continue the discussion for the long term. Its just that no one knew of any easy answers that could be implemented easily, without requiring more work from everyone. The status quo is captured in our current policy statement, at http://wiki.eclipse.org/SimRel/Simultaneous_Release_FAQ#Can_a_new_project_or_feature_join_a_Simultaneous_Service_Release_.28SR1_or_SR2.29.3F In fact, it turns out several strategic adopting members were surprised we allow new features at all ... and wanted the emphasis to stay on bug fixes and quality improvements in the SRs, and to not be surprised by new features. So, we humbling ask projects to announce and summarize here on cross-project list when they are adding new features and when minor versions increment. We definitely want to allow projects to add new features when they need to, based on the needs of their community and adopters ... but don't want to encourage experiments with new features that might not be fully baked yet. So, we'll stick with the restrictions that new releases must be released a month before RC1 and be in RC1, as our policy states. This does not prevent any project from having a new release anytime you want but might mean you can not contribute it to Simultaneous Release maintenance. Hope this helps adds clarity to the current rules for Simultaneous Release maintenance. Thanks, From: Gunnar Wagenknecht gun...@wagenknecht.org To: Cross project issues cross-project-issues-dev@eclipse.org, Date: 08/14/2013 08:55 AM Subject: Re: [cross-project-issues-dev] Question on Kepler SR1 release review Sent by: cross-project-issues-dev-boun...@eclipse.org Am 14.08.2013 um 02:41 schrieb Matthias Sohn matthias.s...@gmail.com: AFAIK if you want to release a pure maintenance release (only bugfixes, no new features) you don't need a release review, if you want to ship new features you need the review. Yes, this is correct. Technically, a pure maintenance (aka. service) releases changes only the 'x' of 'a.b.x' version string. -Gunnar -- Gunnar Wagenknecht gun...@wagenknecht.org ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] new ide-dev mailing list
Agreed. We've had some great discussions here the past few weeks. And I expect we may end up using both. I'd just like to use ide-dev as a landing place for new contributors who are interested in helping and expressing ideas. This is more the vererans's list :) Sent from my BlackBerry 10 smartphone on the Rogers network. From: Wim Jongman Sent: Thursday, August 1, 2013 10:31 AM To: Cross project issues Reply To: Cross project issues Subject: Re: [cross-project-issues-dev] new ide-dev mailing list BTW I am not bashing your idea for an ide-dev list (already signed up), I just wanted to share my view on x-project. On Thu, Aug 1, 2013 at 4:28 PM, Wim Jongman wim.jong...@gmail.commailto:wim.jong...@gmail.com wrote: Hi Doug, Cross project issues was really meant for release train project management issues. Cross-project has evolved to what it is today; a great forum where all the committers hang out to share common themes. I like it a lot. Cheers, Wim On Tue, Jul 30, 2013 at 5:43 PM, Doug Schaefer dschae...@qnx.commailto:dschae...@qnx.com wrote: Hey gang, Denis has set up the ide-dev mailing list for us. Cross project issues was really meant for release train project management issues. I think it would be prudent if we move our IDE focused discussions over there. Feel free to sign up: https://dev.eclipse.org/mailman/listinfo/ide-dev Doug. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Are too many packages actually hurting Eclipse?
That's great question I was asking myself looking at the Download page the other day. I don't think I have a great answer though. I like the idea of the big uber package for the reason you list as #3. I'd like to fix our tools plug-ins to play nicer together. Having this package would give us a test bed to work towards. But it's probably not a great idea for end users, at least not yet. And it certainly isn't a good idea for the Eclipse infrastructure and would chew through way too much bandwidth. Maybe we can use or adapt the Ecilpse Marketplace to make it easier to load up components. The p2 UI is pretty tough on new users. Marketplace client is a much better experience but it's still hard to discover things. But we could provide our own catalog to accomplish this goal. Doug. From: Konstantin Komissarchik konstantin.komissarc...@oracle.commailto:konstantin.komissarc...@oracle.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Monday, 29 July, 2013 6:35 PM To: 'Cross project issues' cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: [cross-project-issues-dev] Are too many packages actually hurting Eclipse? There are twelve packages currently listed on the downloads page, not counting the promoted ones. Are so many packages actually a benefit to users? We try to define packages based on developer profiles, but real developers rarely fit a profile. One of the most common complaints that I have seen on forums are related to difficulties in getting an Eclipse installation that has all the pieces that the developer requires. The ironic thing is that we go through a lot of trouble to define a common repository with components that are known to work with each other, but then fragment the result into a dozen different packages. Would user experience be better if there was only one Eclipse package on the main download site that had pretty much everything that’s in the aggregated repository? Some of the reasons for not doing that… 1. The package would be too large. With modern download speeds, I suspect most users would rather wait a few minutes longer for Eclipse to download than spend time later trying to figure out how to install the missing pieces. The disk space difference is also inconsequential these days. 2. The users prefer to not include pieces in their installation that they don’t use. I can see that being the case for some advanced Eclipse users, but I don’t believe this holds true across the user base. I suspect that most users would rather spend time on their development project than tuning their Eclipse installation. 3. Too many plugins in one installation leads to poor user experience. If there are problems like that, we should be identifying and fixing them. Thoughts? - Konstantin ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Are too many packages actually hurting Eclipse?
BTW, we have a new mailing list that's getting created tonight, ide-dev, which is probably a better place for these types of discussion (since most of the packages are IDE packages). Look for it tomorrow. From: Doug Schaefer dschae...@qnx.commailto:dschae...@qnx.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Monday, 29 July, 2013 8:16 PM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Are too many packages actually hurting Eclipse? That's great question I was asking myself looking at the Download page the other day. I don't think I have a great answer though. I like the idea of the big uber package for the reason you list as #3. I'd like to fix our tools plug-ins to play nicer together. Having this package would give us a test bed to work towards. But it's probably not a great idea for end users, at least not yet. And it certainly isn't a good idea for the Eclipse infrastructure and would chew through way too much bandwidth. Maybe we can use or adapt the Ecilpse Marketplace to make it easier to load up components. The p2 UI is pretty tough on new users. Marketplace client is a much better experience but it's still hard to discover things. But we could provide our own catalog to accomplish this goal. Doug. From: Konstantin Komissarchik konstantin.komissarc...@oracle.commailto:konstantin.komissarc...@oracle.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Monday, 29 July, 2013 6:35 PM To: 'Cross project issues' cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: [cross-project-issues-dev] Are too many packages actually hurting Eclipse? There are twelve packages currently listed on the downloads page, not counting the promoted ones. Are so many packages actually a benefit to users? We try to define packages based on developer profiles, but real developers rarely fit a profile. One of the most common complaints that I have seen on forums are related to difficulties in getting an Eclipse installation that has all the pieces that the developer requires. The ironic thing is that we go through a lot of trouble to define a common repository with components that are known to work with each other, but then fragment the result into a dozen different packages. Would user experience be better if there was only one Eclipse package on the main download site that had pretty much everything that’s in the aggregated repository? Some of the reasons for not doing that… 1. The package would be too large. With modern download speeds, I suspect most users would rather wait a few minutes longer for Eclipse to download than spend time later trying to figure out how to install the missing pieces. The disk space difference is also inconsequential these days. 2. The users prefer to not include pieces in their installation that they don’t use. I can see that being the case for some advanced Eclipse users, but I don’t believe this holds true across the user base. I suspect that most users would rather spend time on their development project than tuning their Eclipse installation. 3. Too many plugins in one installation leads to poor user experience. If there are problems like that, we should be identifying and fixing them. Thoughts? - Konstantin ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Are too many packages actually hurting Eclipse?
+1 for that. I've seen (and made for that matter) commercial products do that. Download a minimal p2 install with an Eclipse application that drives the rest of the install. We could ask for a list of languages or platforms they want to develop for and then install the necessary components. From: Mike Milinkovich mike.milinkov...@eclipse.orgmailto:mike.milinkov...@eclipse.org Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Monday, 29 July, 2013 8:30 PM To: cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org, Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Are too many packages actually hurting Eclipse? Another potential solution that should be on the list for consideration is a reasonably smart installer. Mike Milinkovich mike.milinkov...@eclipse.orgmailto:mike.milinkov...@eclipse.org +1.613.220.3223 From: Doug Schaefer Sent: Monday, July 29, 2013 8:16 PM To: Cross project issues Reply To: Cross project issues Subject: Re: [cross-project-issues-dev] Are too many packages actually hurting Eclipse? That's great question I was asking myself looking at the Download page the other day. I don't think I have a great answer though. I like the idea of the big uber package for the reason you list as #3. I'd like to fix our tools plug-ins to play nicer together. Having this package would give us a test bed to work towards. But it's probably not a great idea for end users, at least not yet. And it certainly isn't a good idea for the Eclipse infrastructure and would chew through way too much bandwidth. Maybe we can use or adapt the Ecilpse Marketplace to make it easier to load up components. The p2 UI is pretty tough on new users. Marketplace client is a much better experience but it's still hard to discover things. But we could provide our own catalog to accomplish this goal. Doug. From: Konstantin Komissarchik konstantin.komissarc...@oracle.commailto:konstantin.komissarc...@oracle.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Monday, 29 July, 2013 6:35 PM To: 'Cross project issues' cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: [cross-project-issues-dev] Are too many packages actually hurting Eclipse? There are twelve packages currently listed on the downloads page, not counting the promoted ones. Are so many packages actually a benefit to users? We try to define packages based on developer profiles, but real developers rarely fit a profile. One of the most common complaints that I have seen on forums are related to difficulties in getting an Eclipse installation that has all the pieces that the developer requires. The ironic thing is that we go through a lot of trouble to define a common repository with components that are known to work with each other, but then fragment the result into a dozen different packages. Would user experience be better if there was only one Eclipse package on the main download site that had pretty much everything that’s in the aggregated repository? Some of the reasons for not doing that… 1. The package would be too large. With modern download speeds, I suspect most users would rather wait a few minutes longer for Eclipse to download than spend time later trying to figure out how to install the missing pieces. The disk space difference is also inconsequential these days. 2. The users prefer to not include pieces in their installation that they don’t use. I can see that being the case for some advanced Eclipse users, but I don’t believe this holds true across the user base. I suspect that most users would rather spend time on their development project than tuning their Eclipse installation. 3. Too many plugins in one installation leads to poor user experience. If there are problems like that, we should be identifying and fixing them. Thoughts? - Konstantin ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Future of Eclipse IDE
Great words Gunnar. It's funny, as a Canadian, I still have hope, dreaming maybe, but hope. And that hope stems from watching the reaction in the room as the Bling IDE guys showed off, not only a really cool SWT port, but their passion for building a modern IDE based on Eclipse targeted at some pretty demanding users. And I felt it in that passion in audience as well. If we could harness that energy, I really think (hope) we can turn this thing around. And it's interesting you bring up JavaFX. It's certainly what Oracle is trying to do with the Java platform. If we could combine forces, start migrating Eclipse towards JavaFX, first by porting SWT over it and then by leveraging e4's renderer framework to go pure JavaFX, it might be something we could get the kids excited about and get a new generation of contributors. Doug. From: Gunnar Wagenknecht gun...@wagenknecht.orgmailto:gun...@wagenknecht.org Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Thursday, 18 July, 2013 5:01 AM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: [cross-project-issues-dev] Future of Eclipse IDE Am 18.07.2013 um 09:59 schrieb Mickael Istria mist...@redhat.commailto:mist...@redhat.com: Eclipse Foundation is IMO the only organization which is able to be efficient at listening to the market of IDEs I strongly disagree with this statement. There are many organizations as well as companies out there that can perform this equally efficient if not better. In fact, there used to be a company in the past. Also, anything the Foundation does is an investment as well. Simply put, in the end someone has to pay for it. BTW, when doing competitive analysis I also disagree with an earlier argument that some ide isn't free and therefore doesn't count. There are a bunch of people out there that would rather spend a two digit amount for something that helps them get their work done more efficiently. Anyway, just looking at the raw numbers, the issue is obvious. There were *a million* commits in the eclipse project (what I consider platform) within three years back in 2004. It was only a good third in the last three years (2010-2012). http://dash.eclipse.org/dash/commits/web-app/summary.cgi Those commits went into a lot of things truly important for innovation higher up the stack (SWT, Text, JFace, Resources). SWT has been in maintenance mode since important committers left. Oracle is investing a lot into JavaFX. There is some shift towards the web. There is a lot innovation happening at Orion. Also, the diversification into areas such as M2M, Polarsys, etc. help the Foundation maintaining a steady interest in the Foundation model. But what does this mean for the IDE? Frankly, I think Orion is too early. There is still much attraction in native IDEs. We all have good ideas to improve the Eclipse IDE in ways we can. I've put energy into a proposal to address the preference issues within the packages. There is progress on this end. I've also put quite a bit energy into improving things in the past as well. There is only so much you can do as a single contributor not even working full-time on things. But I got frustrated along the way. Too much of the platform is still dominated and controlled too strictly by that one single company. Contributions got turned away because of the lack of resources argument and associated maintenance costs long term. To some point those arguments aren't completely invalid. I'm at a point of being resigned when it comes to contributing to the platform. Without a team that is sufficiently funded for an interesting time period, it's only the small steps we can do. I'm wondering if those small steps will be enough for the IDE to have a future. Well, being a German I am actually more concerned than wondering but I consider this a better thing than not caring at all. I really appreciate the time and energy people are spending on this discussion. -Gunnar -- Gunnar Wagenknecht gun...@wagenknecht.orgmailto:gun...@wagenknecht.org ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Future of Eclipse IDE
Thanks John. I'm glad you commented. And you are right, I think the problem is just perception and based more on the past than the present. And, in many ways, it's those changes that help give me hope. If we do get more people interested in contributing, we have a much better ability at affecting change now than we ever have. Doug. From: John Arthorne john_artho...@ca.ibm.commailto:john_artho...@ca.ibm.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Thursday, 18 July, 2013 4:17 PM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Future of Eclipse IDE Gunnar Wagenknecht wrote on 07/18/2013 05:01:50 AM: Too much of the platform is still dominated and controlled too strictly by that one single company. Contributions got turned away because of the lack of resources argument and associated maintenance costs long term. To some point those arguments aren't completely invalid. I'm at a point of being resigned when it comes to contributing to the platform. This statement worries me more than everything else that has been written in this thread. It makes sense that there are very few committers who are focused on the requirements of the direct Eclipse user base. There are few people with the motivation to even gather feedback on the pain points of using a free tool, let alone spending significant time addressing them. I believe the main focus for most current committers is: 1) Stuff *they* (or their employer) want to focus on 2) Enabling other contributors to help *them* fix the problems they want to see fixed I think this is one of Doug's key points, that working to enable more contributors is the only scalable solution. Imagine someone spent the time to gather a list of the top 5 most pressing problems/enhancement requests. Maybe the current committers can take this list and fix 1 or 2 of them between their other priorities. Well, next year there will be a new list, and more requests, and still no more people to work on them. It will not result in a dramatic transformation of the perception or trajectory of Eclipse as an IDE. However Gunnar's comment says we are even failing on enabling contributors, which vexes me. I actually thought we had made improvements on that in the past couple of years. The Foundation and many committers have been working to reduce barriers to contribution in any way possible. Switching to Git, moving the build to Maven/Tycho, adopting Gerrit, and holding dedicated patch review days are a few of the things committers have been doing. From the statistics it looks like we are even starting to see results on this. Ohloh metrics have shown a stable or even slight upwards trend in the number of Platform contributors in the past couple of years [1]. JDT core and SWT, historically the two components with the toughest standards for accepting committers, have both seen committers from new companies this year. Platform UI, which is in a position to address many of the preference problems described here, has THIRTY NINE committers. I don't doubt there are still barriers, but it looks like at least some people are managing to overcome them and bring their contributions into the platform. Personally most the time I used to spend directly fixing user reported problems, I now spend reviewing patches and trying to enable others to contribute fixes instead. If successful, this has a multiplier effect that grows the base of people capable of contributing and is, I think, the best use of the limited committer resources we have available. So don't tell me what you want to see fixed. Tell me how I can help you to fix them. John [1] https://www.ohloh.net/p/eclipse/factoids#FactoidTeamSizeVeryLarge ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Preferences (topic was touched in Eclipse smells kind of dead thread)
You are right. I'm in that same situation. But I'm not sure the Foundation has the resources either. That's why we need to grow the contributor community. The more hands we have on deck the more we can do this kind of analysis and planning and get things done. Doug. From: Mickael Istria mist...@redhat.commailto:mist...@redhat.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Wednesday, 17 July, 2013 12:38 PM To: cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Preferences (topic was touched in Eclipse smells kind of dead thread) On 07/17/2013 06:23 PM, Doug Schaefer wrote: My answer: It's something I expect the PMC to provide. Which PMC that is, is being discussed on another thread somewhere. The issue with this approach is that the PMC is made of contributors who already have job to do at their company + some leadership to provide in the Eclipse community. Does the PMC really have time to do this task correctly? IMHO, the PMC should be the first consumer of such reports, not the provider. -- Mickael Istria Eclipse developer at JBoss, by Red Hathttp://www.jboss.org/tools My bloghttp://mickaelistria.wordpress.com - My Tweetshttp://twitter.com/mickaelistria ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Preferences (topic was touched in Eclipse smells kind of dead thread)
Thanks Mike. Spot on. But I do have one comment with all due respect. I'm not sure why we're always expecting companies to drop bus loads of developers into projects when we have a pretty healthy individual contributor community already at Eclipse. In fact, over half of CDT contributions of late are coming from individuals, not companies. And it's really coming from users who have the skills to contribute back and not only make their lives better, but others as well, and get rewarded by seeing their work on the big stage. So really, the changes I'm talking about, more frequent release cycles, creating a list of features and bugs we'd like fixed, is aimed at attracting more individuals to the party. And I'm pretty sure there are some companies who would like to see the same. Create the buzz and companies may take another look. And I can't help consider even the time people are putting into responding to this thread, that we do have resources available to move the yardsticks forward. And I think we already have… Doug. From: Mike Milinkovich mike.milinkov...@eclipse.orgmailto:mike.milinkov...@eclipse.org Organization: Eclipse Foundation Reply-To: mike.milinkov...@eclipse.orgmailto:mike.milinkov...@eclipse.org mike.milinkov...@eclipse.orgmailto:mike.milinkov...@eclipse.org, Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Wednesday, 17 July, 2013 2:58 PM To: 'Mickael Istria' mist...@redhat.commailto:mist...@redhat.com, 'Cross project issues' cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Preferences (topic was touched in Eclipse smells kind of dead thread) Mickael, These are general comments, and are certainly not meant as a criticism of you or Red Hat. You guys are very helpful in a lot of critical areas. That said… I could imagine the Eclipse Foundation doing something along these lines. But I am not really sure it is of much value if there are no resources to work on things. The status quo for quite some time has been that there are insufficient resources helping on the platform to make the progress we all want. Actually, it’s not just the platform: it is pretty much everything under the topic of code and processes involved in the “common good”. Has something changed in these areas to warrant the EF to make such an investment? In addition to the above, it seems that a lot of the user issues I’ve seen are specifically related to the Java IDE. We can talk all we want about how Eclipse is a general platform and there are many tools and languages supported, but for the vast majority of users the Java development tools is what they mean when they say “Eclipse”. The Java IDE is another area which has felt under-resourced for a long time. Are there resources – including user experience resources – available to make significant enhancements there? Complaining about the status quo is always good sport. Actually showing up with the developers necessary to make and maintain those changes is how we tell who’s serious around here. I am certainly not going to have the EF promote a bunch of changes to the release train process, the EPP packaging process, end-user feature analysis, etc. unless the people and companies calling for change actually commit some long-term resources for both the enhancements and operations needed. Or alternatively they can demonstrate that the people currently keeping these processes together are happy to make some changes. If anyone wants to educate me about how there are new resources available, or how existing resources can be re-allocated to make some significant progress please feel free to contact me either publicly or privately. I would _love_ to see improvements in all of these areas. Mike Milinkovich mike.milinkov...@eclipse.orgmailto:mike.milinkov...@eclipse.org +1.613.220.3223 From: Mickael Istria [mailto:mist...@redhat.com] Sent: July-17-13 11:53 AM To: mike.milinkov...@eclipse.orgmailto:mike.milinkov...@eclipse.org; Cross project issues Subject: Re: [cross-project-issues-dev] Preferences (topic was touched in Eclipse smells kind of dead thread) On 07/17/2013 04:29 PM, Mike Milinkovich wrote: If we’re looking for user feedback, reading the article and comments here[1] would be helpful. Gathering the feedback and reacting to it based on end-users request is not something Eclipse contributors generally excel at doing. The main entry-point for contributors is Bugzilla, which doesn't reflect the real concerns of most users. I guess having the Foundation gathering such external feedback and create reports per project saying Here is what people like and didn't like about your project in the last 3 monthes could help project to identify what is critical for better adoption. Is this something we could imagine the Foundation to provide ? Does it make sense? -- Mickael Istria Eclipse developer at
Re: [cross-project-issues-dev] Preferences (topic was touched in Eclipse smells kind of dead thread)
Just to be clear, I did not suggest the Foundation should help. They are just as resource constrained as the rest of us. And I don't want to the discussion to go in this direction. Let's keep focus on the types of things we want to see fixed and features added and try to figure out how to attract developers to contribute to that effort. Doug. From: Konstantin Komissarchik konstantin.komissarc...@oracle.commailto:konstantin.komissarc...@oracle.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Wednesday, 17 July, 2013 4:07 PM To: 'Cross project issues' cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Preferences (topic was touched in Eclipse smells kind of dead thread) +1 to what Doug is saying. All the discussions that I have seen are either about being more responsive to the community (faster release train) or better understanding the community. This is exactly the type of the common good that Eclipse Foundation can and should help with. - Konstantin From: cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Doug Schaefer Sent: Wednesday, July 17, 2013 12:50 PM To: mike.milinkov...@eclipse.orgmailto:mike.milinkov...@eclipse.org; Cross project issues; 'Mickael Istria' Subject: Re: [cross-project-issues-dev] Preferences (topic was touched in Eclipse smells kind of dead thread) Thanks Mike. Spot on. But I do have one comment with all due respect. I'm not sure why we're always expecting companies to drop bus loads of developers into projects when we have a pretty healthy individual contributor community already at Eclipse. In fact, over half of CDT contributions of late are coming from individuals, not companies. And it's really coming from users who have the skills to contribute back and not only make their lives better, but others as well, and get rewarded by seeing their work on the big stage. So really, the changes I'm talking about, more frequent release cycles, creating a list of features and bugs we'd like fixed, is aimed at attracting more individuals to the party. And I'm pretty sure there are some companies who would like to see the same. Create the buzz and companies may take another look. And I can't help consider even the time people are putting into responding to this thread, that we do have resources available to move the yardsticks forward. And I think we already have… Doug. From: Mike Milinkovich mike.milinkov...@eclipse.orgmailto:mike.milinkov...@eclipse.org Organization: Eclipse Foundation Reply-To: mike.milinkov...@eclipse.orgmailto:mike.milinkov...@eclipse.org mike.milinkov...@eclipse.orgmailto:mike.milinkov...@eclipse.org, Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Wednesday, 17 July, 2013 2:58 PM To: 'Mickael Istria' mist...@redhat.commailto:mist...@redhat.com, 'Cross project issues' cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Preferences (topic was touched in Eclipse smells kind of dead thread) Mickael, These are general comments, and are certainly not meant as a criticism of you or Red Hat. You guys are very helpful in a lot of critical areas. That said… I could imagine the Eclipse Foundation doing something along these lines. But I am not really sure it is of much value if there are no resources to work on things. The status quo for quite some time has been that there are insufficient resources helping on the platform to make the progress we all want. Actually, it’s not just the platform: it is pretty much everything under the topic of code and processes involved in the “common good”. Has something changed in these areas to warrant the EF to make such an investment? In addition to the above, it seems that a lot of the user issues I’ve seen are specifically related to the Java IDE. We can talk all we want about how Eclipse is a general platform and there are many tools and languages supported, but for the vast majority of users the Java development tools is what they mean when they say “Eclipse”. The Java IDE is another area which has felt under-resourced for a long time. Are there resources – including user experience resources – available to make significant enhancements there? Complaining about the status quo is always good sport. Actually showing up with the developers necessary to make and maintain those changes is how we tell who’s serious around here. I am certainly not going to have the EF promote a bunch of changes to the release train process, the EPP packaging process, end-user feature analysis, etc. unless the people and companies calling for change actually commit some long-term resources for both the enhancements
Re: [cross-project-issues-dev] Preferences (topic was touched in Eclipse smells kind of dead thread)
The secret is simple. Manage the project differently, if barely at all. Let the contributors manage it. Be open, really open. And automate as much as you can so you aren't relying on individuals so much. Hell, I've managed to do that with our commercial product builds. (Jenkins, uh, I mean Hudson/Tycho rule!). On 13-07-17 4:13 PM, Mike Milinkovich mike.milinkov...@eclipse.org wrote: I'm not sure why we're always expecting companies to drop bus loads of developers into projects when we have a pretty healthy individual contributor community already at Eclipse. In fact, over half of CDT contributions of late are coming from individuals, not companies. And it's really coming from users who have the skills to contribute back and not only make their lives better, but others as well, and get rewarded by seeing their work on the big stage. That is really good news for CDT. I wish we had a lot more projects that were in your position. But the flip side is that the platform is not in that position today. Others will have to speak to what it will take to get to a position as enviable as CDT's. In addition, the key resources that we have supporting the simultaneous release process like David and Markus are, in fact, supported by member companies. And as far as I know, they are tapped out. I do not think that we can realistically ask them to do more. And if we want them to do something different, I for one would prefer to hear from them what they would like to change. Maybe I'm wrong, and they would be perfectly happy to push out two release trains a year (for example). So really, the changes I'm talking about, more frequent release cycles, creating a list of features and bugs we'd like fixed, is aimed at attracting more individuals to the party. And I'm pretty sure there are some companies who would like to see the same. Create the buzz and companies may take another look. We are certainly agreed about the need to attract more contributors of all types. The Eclipse Foundation has also been pushing this agenda for the last couple of years. Embracing git, implementing CBI, project hosting at GitHub, and switching to CLAs are all examples of things that we did specifically to help reduce barriers to contribution. I agree that we need to increase the pace of innovation. My point is that I don't see a realistic discussion on this thread about resourcing the changes that we would all like to see. I would love to be wrong. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Preferences (topic was touched in Eclipse smells kind of dead thread)
all the ui information is stored. I'd like to always use the same UI for the same type of task regardless of where the projects / files reside. We've already started looking into how we might support a 'common' UI setup in Luna. Basically it would try to separate the UI from the workspace as well as allowing different setups based on the type of work you are doing. The current approach would effectively override the current mechanism(s) to gain access to the '.metadata' to allow a choice between using the workspace's location or the 'common' one. The main issue is to determine *which* metadata is common vs workspace oriented. The best approach I can think of would be an 'opt in' one where a component would declare which of its 'plugins' directories can be 'common'. The platform would then use this info when providing the path to store the information for a particular bundle... Do you think that this can work ? For the UI certainly but without capturing things like dialog settings and ui preferences it's not likely to be seen as a huge gain. My guess is that of all the information we save in '.metadata' most is not really specific to a particular workspace. I realize after talking to McQ that how to split up preferences has proven in the past to be a very difficult problem. How about if the user just exports whatever prefs they're interested in to the 'common' area and we auto-import these whenever we're working against a new workspace ? Onwards, Eric Doug Schaefer ---07/15/2013 01:23:51 PM---It may be hard, but it's is one huge item that we've all run into with our users. It's probably wort From: Doug Schaefer dschae...@qnx.commailto:dschae...@qnx.com To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org, Date: 07/15/2013 01:23 PM Subject: Re: [cross-project-issues-dev] Preferences (topic was touched in Eclipse smells kind of dead thread) Sent by: cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org It may be hard, but it's is one huge item that we've all run into with our users. It's probably worth the price. From: Pascal Rapicault pascal.rapica...@ericsson.commailto:pascal.rapica...@ericsson.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Monday, 15 July, 2013 6:55 PM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Preferences (topic was touched in Eclipse smells kind of dead thread) Internally the preferences are already organized in “scopes” that are: - Project - Workspace - Configuration - (There is no such thing as “system”) However the user does not have a say as in the scope in which a value should be stored. This is mostly because creating a UI for this is hard (we explored some things back in the 3.0 days when we introduced the scope mechanism). From: cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Henrik Sent: July-15-13 12:45 PM To: Cross project issues Subject: [cross-project-issues-dev] Preferences (topic was touched in Eclipse smells kind of dead thread) Hi all, I know that preferences can be imported/exported. Yet I find it a bit cumbersome to care about that every time I create a new workspace. Wouldn't it make sense to have preferences arranged in several layers similar to git: system/user/workspace? Also I could imagine to offer a web page with collections of preference settings. They could be ordered in categories (maybe aligned to the packaged Eclipse installations). And we could offer a possibility for users to cast their vote to be able to rank the settings. -Henrik___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev - compeople AG Untermainanlage 8 60329 Frankfurt/Main fon: +49 (0) 69 / 27 22 18 0 fax: +49 (0) 69 / 27 22 18 22 web: www.compeople.dehttp://www.compeople.de/ Vorstand: Jürgen Wiesmaier Aufsichtsratsvorsitzender: Christian Glanz Sitz der Gesellschaft: Frankfurt/Main Handelsregister Frankfurt HRB 56759 USt-IdNr. DE207665352 -[attachment graycol.gif deleted by Daniel Megert/Zurich/IBM] [attachment ecblank.gif deleted by Daniel Megert/Zurich/IBM] ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] 6 month release cycle
+1 We're going to run into this with CDT. We will want to update the package every 6 months as well. From: Greg Watson g.wat...@computer.orgmailto:g.wat...@computer.org Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Tuesday, 16 July, 2013 4:13 PM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] 6 month release cycle While I support more frequent release cycles (PTP release more frequently so it would suit us well), I'd like to also suggest that projects also have more control over the packages available on the download site. In particular, we'd like to be able to update our package with a new build when we bring out a bug fix release so that new users don't need to update the package as soon as they download it. If you're interested in discussing this more, I've opened bug 412864 on this issue. Greg On Jul 2, 2013, at 3:30 PM, Doug Schaefer dschae...@qnx.commailto:dschae...@qnx.com wrote: Hey gang, We have a discussion going in the CDT community and we are currently planning out how to achieve a 6 month release cycle. The feeling is that we need to get new features out faster to our users. The year long wait we currently have is making releases sluggish and I fear it's slowing down growth in our community. A 6 month cycle should infuse us with a little more energy, so goes the hope. I mentioned CDT's plans on twitter and a number of senior members of our larger Eclipse community thought it might be a good idea for other projects at Eclipse and maybe for the train itself. And I think so too. Instead of continuing that discussion on twitter, which is fun and everything, I thought we should bring that to a greater audience and see what other projects thought and whether it's something we should bring to the Planning Council and the rest of the EMO. I know there are a number of projects already releasing off stream during the year, but bringing things together more often might be a help to many others. But I'd like to hear your thoughts on that. Doug. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Preferences (topic was touched in Eclipse smells kind of dead thread)
It may be hard, but it's is one huge item that we've all run into with our users. It's probably worth the price. From: Pascal Rapicault pascal.rapica...@ericsson.commailto:pascal.rapica...@ericsson.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Monday, 15 July, 2013 6:55 PM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Preferences (topic was touched in Eclipse smells kind of dead thread) Internally the preferences are already organized in “scopes” that are: - Project - Workspace - Configuration - (There is no such thing as “system”) However the user does not have a say as in the scope in which a value should be stored. This is mostly because creating a UI for this is hard (we explored some things back in the 3.0 days when we introduced the scope mechanism). From: cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Henrik Sent: July-15-13 12:45 PM To: Cross project issues Subject: [cross-project-issues-dev] Preferences (topic was touched in Eclipse smells kind of dead thread) Hi all, I know that preferences can be imported/exported. Yet I find it a bit cumbersome to care about that every time I create a new workspace. Wouldn't it make sense to have preferences arranged in several layers similar to git: system/user/workspace? Also I could imagine to offer a web page with collections of preference settings. They could be ordered in categories (maybe aligned to the packaged Eclipse installations). And we could offer a possibility for users to cast their vote to be able to rank the settings. -Henrik ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] [Doug on the Eclipse CDT] New comment on Eclipse smells kind of dead???.
The line numbers is a great example. There is no way to win other than make it easy to turn on. And, yes, the preferences is an absolute mess. New users are intimidated when they open it up by all the choices. Same thing happens when they open the context menu in the project navigator and editors. We've built a great UI framework at Eclipse. Every plugin is allowed to add anything they want to the preferences, menus, and toolbars. And they do so a lot and inconsistent ways and it ends up a mess. We need some way to clean it up and simplify the UI for the majority of the users that need it. Doug. From: Ed Merks Sent: Saturday, July 13, 2013 8:47 AM To: cross-project-issues-dev@eclipse.org Reply To: Cross project issues Subject: Re: [cross-project-issues-dev] [Doug on the Eclipse CDT] New comment on Eclipse smells kind of dead???. Fabian, Comments below. On 13/07/2013 1:57 PM, Fabian Steeg wrote: I think the discussion about getting new contributors is good and important. Just one thought on a different aspect however: it seems many user issues come down to the default settings (about half of the top 10 on the site, and both bugs mentioned by Denis). Yes, I was just chatting to someone else about that today. Changing them has been tried and doesn't seem to work. No, it will just annoy the hell out of people, much like the latest software update made all my firefox tabs bigger. I didn't ask for that and had to Google to find out how to make them smaller again, and even now, that style setting makes the font smaller, so it just don't look the same anymore (the same size tabs but smaller fonts). It's just not an improvement! I really hate it, though I don't hate firefox! Could some sort of settings profiles/themes help instead? How about something like a prominent configure on the welcome page which brings up a wizard that includes the top 10 settings for behaviors that people complain and are completely configurable to eliminate those complaints. I'm thinking something like an option to select the settings profile in the workspace selection dialog - out of the box there could simply be two options: 'built-in Eclipse settings' and 'Eclipse community settings' (which could be the most starred settings profile available on the marketplace or so). It would still be nice to easily deviate from this, without having to find the preferences in the rat's nest of preference. Determining the most hated default settings and the most hated behaviors configurable via settings and making the user aware of their total control over these things on first start up seems like a good solution. This could not only fix issues that make people angry, but on the positive side also introduce them to many awesome Eclipse features they didn't know about, and increase the feeling of community influence on how Eclipse behaves. I agree that something along these lines would be a good thing to explore. It's silly to have people hate Eclipse because it doesn't show line numbers by default in the text editors. I personally hate line numbers. They're a waste of valuable space. But that's just my biased opinion. Cheers, Fabian On 12.07.2013, at 18:25, Doug Schaefer dschae...@qnx.commailto:dschae...@qnx.com wrote: It is. And I'm sure there are hate sites for every tool people use. Eclipse isn't unique that way. My point is that user experience is so important to our success, we need to be sensitive to the issues our users are facing. There are a lot of such issues marked WONTFIX, and CDT is as guilty of that as anyone. I'm just wondering how we fix it. Doug. From: Denis Roy denis@eclipse.orgmailto:denis@eclipse.org Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Friday, 12 July, 2013 5:54 PM To: cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] FW: [Doug on the Eclipse CDT] New comment on Eclipse smells kind of dead???. Actually, I think it is awesome feedback, since there are only a handful of issues that seem to raise the anger levels. I was able to trace a few of the top items to some old bugs: File out of sync: https://bugs.eclipse.org/bugs/show_bug.cgi?id=228039 Line numbers on by default: https://bugs.eclipse.org/bugs/show_bug.cgi?id=191154 Those bugs are fairly old and both are closed WONTFIX. It would be interesting if they could be reopened for discussion. Denis On 07/12/2013 11:31 AM, Doug Schaefer wrote: http://www.ihateeclipse.comhttp://www.ihateeclipse.com/ ??? Pretty awesome feedback from our passionate user base. :D From: cdtd...@gmail.commailto:cdtd...@gmail.com cdtd...@gmail.commailto:cdtd...@gmail.com Date: Friday, 12 July, 2013 5:29 PM To: Doug Schaefer dschae...@qnx.commailto:dschae...@qnx.com Subject: Fw: [Doug
Re: [cross-project-issues-dev] FW: [Doug on the Eclipse CDT] New comment on Eclipse smells kind of dead???.
It is. And I'm sure there are hate sites for every tool people use. Eclipse isn't unique that way. My point is that user experience is so important to our success, we need to be sensitive to the issues our users are facing. There are a lot of such issues marked WONTFIX, and CDT is as guilty of that as anyone. I'm just wondering how we fix it. Doug. From: Denis Roy denis@eclipse.orgmailto:denis@eclipse.org Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Friday, 12 July, 2013 5:54 PM To: cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] FW: [Doug on the Eclipse CDT] New comment on Eclipse smells kind of dead???. Actually, I think it is awesome feedback, since there are only a handful of issues that seem to raise the anger levels. I was able to trace a few of the top items to some old bugs: File out of sync: https://bugs.eclipse.org/bugs/show_bug.cgi?id=228039 Line numbers on by default: https://bugs.eclipse.org/bugs/show_bug.cgi?id=191154 Those bugs are fairly old and both are closed WONTFIX. It would be interesting if they could be reopened for discussion. Denis On 07/12/2013 11:31 AM, Doug Schaefer wrote: http://www.ihateeclipse.com ??? Pretty awesome feedback from our passionate user base. :D From: cdtd...@gmail.commailto:cdtd...@gmail.com cdtd...@gmail.commailto:cdtd...@gmail.com Date: Friday, 12 July, 2013 5:29 PM To: Doug Schaefer dschae...@qnx.commailto:dschae...@qnx.com Subject: Fw: [Doug on the Eclipse CDT] New comment on Eclipse smells kind of dead???. From: Alex Lagarde Sent: Friday, July 12, 2013 11:25 AM To: cdtd...@gmail.commailto:cdtd...@gmail.com Subject: [Doug on the Eclipse CDT] New comment on Eclipse smells kind of dead???. Alex Lagardehttp://www.blogger.com/profile/06754768116468218364 has left a new comment on your post Eclipse smells kind of dead???http://cdtdoug.blogspot.com/2013/07/eclipse-smells-kind-of-dead.html: Interesting post. Maybe even worst than bugzillas that get no answer are general complaints about Eclipse/Projects that never were raised as issues. That's why this Website, as painfull as it is, provides very interesting feedback http://www.ihateeclipse.com/ We may have to think about a better way for end-user to raise such feelings (maybe an amazon-like rating system which would allow to very quickly rate from 0 to 5 stars a feature or a project). Posted by Alex Lagarde to Doug on the Eclipse CDThttp://cdtdoug.blogspot.com/ at 4:25 PM GMT+1 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.orghttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] FW: [Doug on the Eclipse CDT] New comment on Eclipse smells kind of dead???.
I'm sure your powers that be will tell you we've all been trying that for years. Eclipse doesn't suck enough for that to work, which is a good thing in a way. That's why I hope we can aim at the grassroots people, individual users, who have the skills to help. Doug. From: Denis Roy denis@eclipse.orgmailto:denis@eclipse.org Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Friday, 12 July, 2013 6:50 PM To: cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] FW: [Doug on the Eclipse CDT] New comment on Eclipse smells kind of dead???. On 07/12/2013 12:25 PM, Doug Schaefer wrote: It is. And I'm sure there are hate sites for every tool people use. Eclipse isn't unique that way. My point is that user experience is so important to our success, we need to be sensitive to the issues our users are facing. There are a lot of such issues marked WONTFIX, and CDT is as guilty of that as anyone. I'm just wondering how we fix it. As a committer, I'd be selling the community needs to BigCorp management. If BigCorp's products are built on Eclipse, and Eclipse comes to have the reputation of suck, then BigCorp's products will inherit that. Since the users of today are the managers of tomorrow, these managers won't purchase products that are based on suck. I'll do my part here: I think the eclipse.org website (including the Bugzilla UI) is starting to suck, and I've already begun selling the idea to the powers that be. Not that they need much convincing :) D. Doug. From: Denis Roy denis@eclipse.orgmailto:denis@eclipse.org Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Friday, 12 July, 2013 5:54 PM To: cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] FW: [Doug on the Eclipse CDT] New comment on Eclipse smells kind of dead???. Actually, I think it is awesome feedback, since there are only a handful of issues that seem to raise the anger levels. I was able to trace a few of the top items to some old bugs: File out of sync: https://bugs.eclipse.org/bugs/show_bug.cgi?id=228039 Line numbers on by default: https://bugs.eclipse.org/bugs/show_bug.cgi?id=191154 Those bugs are fairly old and both are closed WONTFIX. It would be interesting if they could be reopened for discussion. Denis On 07/12/2013 11:31 AM, Doug Schaefer wrote: http://www.ihateeclipse.com ??? Pretty awesome feedback from our passionate user base. :D From: cdtd...@gmail.commailto:cdtd...@gmail.com cdtd...@gmail.commailto:cdtd...@gmail.com Date: Friday, 12 July, 2013 5:29 PM To: Doug Schaefer dschae...@qnx.commailto:dschae...@qnx.com Subject: Fw: [Doug on the Eclipse CDT] New comment on Eclipse smells kind of dead???. From: Alex Lagarde Sent: Friday, July 12, 2013 11:25 AM To: cdtd...@gmail.commailto:cdtd...@gmail.com Subject: [Doug on the Eclipse CDT] New comment on Eclipse smells kind of dead???. Alex Lagardehttp://www.blogger.com/profile/06754768116468218364 has left a new comment on your post Eclipse smells kind of dead???http://cdtdoug.blogspot.com/2013/07/eclipse-smells-kind-of-dead.html: Interesting post. Maybe even worst than bugzillas that get no answer are general complaints about Eclipse/Projects that never were raised as issues. That's why this Website, as painfull as it is, provides very interesting feedback http://www.ihateeclipse.com/ We may have to think about a better way for end-user to raise such feelings (maybe an amazon-like rating system which would allow to very quickly rate from 0 to 5 stars a feature or a project). Posted by Alex Lagarde to Doug on the Eclipse CDThttp://cdtdoug.blogspot.com/ at 4:25 PM GMT+1 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] 6 month release cycle
I wonder, for those companies that want stability, should they focus on the LTS program where old releases are maintained for long periods of time. I'm of the opinion that the entire stack needs new feature development, at least on the IDE side. We are falling behind the competition and my thinking and hope is that releasing more often would help energize the community. On 13-07-03 6:10 AM, Ed Merks ed.me...@gmail.com wrote: Releasing more often sounds like a good thing in principle and of course projects are free to do so as they wish. One major concern I'd have about the release train itself releasing more often is the long ramp down cycle appearing twice as often per year. Of course the M/RC phase would need to be shorted, but then the question is, why is it currently so long? I expect the answer if to provide quality and stability, so would that inevitably suffer as a result? That would be a bad thing... Another question we must ask is what's best for the consumers/adopters? On the one hand, I imagine for projects with very active feature development, many of their consumers do want the latest and greatest as often as possible. On the other hand, I also imagine that a great many commercial adopters see quality and stability as their primary criteria for adoption and hence see more value in SR1 and SR2 releases of a stable base that's focused primarily on quality improvements compared to all the new feature development, which is almost inevitably associated with lower quality. On 03/07/2013 11:44 AM, Krzysztof Daniel wrote: For Eclipse as a product it is definitely good to have releases more often. It will lower the entry barrier (patches could find a way in the release in less then a year), and will attract new contributors. BUT at the same time there is Eclipse as a platform, with API compatibility, with service releases and specific change management policies, which is totally different from the Eclipse-As-A-Product. So, maybe the key point is that there is a need for two lines: - release train, kept as it is currently - rolling release - it is a product. rather for users then for developers. New API and features can be withdrawn. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] 6 month release cycle
How often do the Eclipse packages get build and tested and what appears on the Eclipse download page? On 13-07-03 12:02 PM, Konstantin Komissarchik konstantin.komissarc...@oracle.com wrote: Glad to see interest in my frequent aggregation proposal. To answer some of the questions that were raised... 1. Monthly releases sounds rather too frequent. Doesn't leave a lot of room for milestones or IP team to do their work. Projects would release at whatever pace makes sense to them, set their own schedules and leave room for IP team to do their work. Some would continue to release yearly, some would be on a six month cycle, some would release even more frequently. The aggregation stream would only accept a finished release. In fact, given enough automation, the aggregation can become continuous. Suppose that instead of the current system where projects edit stuff in Git, there is a portal where projects contribute their release. Verification runs automatically, if it fails, the contribution is rejected. No more missing about.html files! The tool can also be available on verify only basis for projects wishing to check their release candidates. 2. What happens if there is a dependency conflict? For instance, if GEF pushes a new release, but the contributed GMF release still depends on the old version. We would very likely need to allow multiple versions in the repository for frequent aggregation to work. Perhaps only the latest version is categorized. 3. Should the aggregated repository be verified? Yes. The primary value of the aggregated repository is that there is a version of each component that can be installed together. If we don't verify at aggregation time, we will lose that feature. However, with multiple versions being present, the verification would need to be different. Instead of verifying if everything can be installed together, it should verify if a solution exists such that at least one version of each component can be installed with everything else. 4. What about LTS and others who want more stability. Do we still need the current release train for that? Not really. Let's call what I've described the latest stream. Periodically, the latest stream can be branched to create a stable stream of a given vintage. Projects can still contribute to the stable stream, but the rules are different (stricter). On the opposite end, we could also have a dev stream, where projects can contribute their latest milestone builds, integration builds, etc. 5. What would I build against? Projects should be tracking the release plans of their dependencies and build directly against the repositories published by their dependencies. Building against any aggregation stream is risky since you never know which version you are building against and you lose ability to reproduce your build. Thanks, - Konstantin ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] 6 month release cycle
Hey gang, We have a discussion going in the CDT community and we are currently planning out how to achieve a 6 month release cycle. The feeling is that we need to get new features out faster to our users. The year long wait we currently have is making releases sluggish and I fear it's slowing down growth in our community. A 6 month cycle should infuse us with a little more energy, so goes the hope. I mentioned CDT's plans on twitter and a number of senior members of our larger Eclipse community thought it might be a good idea for other projects at Eclipse and maybe for the train itself. And I think so too. Instead of continuing that discussion on twitter, which is fun and everything, I thought we should bring that to a greater audience and see what other projects thought and whether it's something we should bring to the Planning Council and the rest of the EMO. I know there are a number of projects already releasing off stream during the year, but bringing things together more often might be a help to many others. But I'd like to hear your thoughts on that. Doug. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] 6 month release cycle
Funny, that came up in our conversation too. Years ago, M releases were awesome. They always had new features and the quality was pretty good. But then the quality stopped being so good and there were less features, so people cared less about M releases. And that has left a long period of time where people really care about Eclipse releases. D From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Igor Fedorenko [ifedore...@sonatype.com] Sent: Tuesday, July 02, 2013 3:49 PM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] 6 month release cycle I agree, one year is way too long. I am not even sure 6 months is often enough. We had three m2e releases between Juno and Kepler, and I consider m2e mature, (relatively) low-activity project. At the same time, I never use R builds myself, I always use M-builds as primary development environment for my $DAY_JOB. I don't suggest we do full-blown release every 6 weeks, but maybe there is a way to elevate perceived status of M builds such that users are more comfortable using them. -- Regards, Igor On 2013-07-02 11:30 PM, Doug Schaefer wrote: Hey gang, We have a discussion going in the CDT community and we are currently planning out how to achieve a 6 month release cycle. The feeling is that we need to get new features out faster to our users. The year long wait we currently have is making releases sluggish and I fear it's slowing down growth in our community. A 6 month cycle should infuse us with a little more energy, so goes the hope. I mentioned CDT's plans on twitter and a number of senior members of our larger Eclipse community thought it might be a good idea for other projects at Eclipse and maybe for the train itself. And I think so too. Instead of continuing that discussion on twitter, which is fun and everything, I thought we should bring that to a greater audience and see what other projects thought and whether it's something we should bring to the Planning Council and the rest of the EMO. I know there are a number of projects already releasing off stream during the year, but bringing things together more often might be a help to many others. But I'd like to hear your thoughts on that. Doug. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] 6 month release cycle
Spurring on the development of new features is part of what's driving this. Only the early adopters ever download milestone builds and we're trying to be more agile to a larger audience by going twice as often. D On 13-07-02 4:17 PM, Igor Fedorenko ifedore...@sonatype.com wrote: What's the point of releasing often if there are no new features? -- Regards, Igor On 2013-07-02 11:56 PM, Doug Schaefer wrote: Funny, that came up in our conversation too. Years ago, M releases were awesome. They always had new features and the quality was pretty good. But then the quality stopped being so good and there were less features, so people cared less about M releases. And that has left a long period of time where people really care about Eclipse releases. D From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Igor Fedorenko [ifedore...@sonatype.com] Sent: Tuesday, July 02, 2013 3:49 PM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] 6 month release cycle I agree, one year is way too long. I am not even sure 6 months is often enough. We had three m2e releases between Juno and Kepler, and I consider m2e mature, (relatively) low-activity project. At the same time, I never use R builds myself, I always use M-builds as primary development environment for my $DAY_JOB. I don't suggest we do full-blown release every 6 weeks, but maybe there is a way to elevate perceived status of M builds such that users are more comfortable using them. -- Regards, Igor On 2013-07-02 11:30 PM, Doug Schaefer wrote: Hey gang, We have a discussion going in the CDT community and we are currently planning out how to achieve a 6 month release cycle. The feeling is that we need to get new features out faster to our users. The year long wait we currently have is making releases sluggish and I fear it's slowing down growth in our community. A 6 month cycle should infuse us with a little more energy, so goes the hope. I mentioned CDT's plans on twitter and a number of senior members of our larger Eclipse community thought it might be a good idea for other projects at Eclipse and maybe for the train itself. And I think so too. Instead of continuing that discussion on twitter, which is fun and everything, I thought we should bring that to a greater audience and see what other projects thought and whether it's something we should bring to the Planning Council and the rest of the EMO. I know there are a number of projects already releasing off stream during the year, but bringing things together more often might be a help to many others. But I'd like to hear your thoughts on that. Doug. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] 6 month release cycle
We're still debating what to do with the SR-2. The proposal was an early conservative one that was aimed to appease the community that doesn't want to live on the bleeding edge. Egit, you pretty much have to live on the bleeding edge since it's still pushing some basic features that everyone needs. But I could see us forgoing SR-2 altogether at some point and release the Dec CDT release at SR-2 time. I just think releasing random lineups every 4 months as somewhat happens now with those projects doesn't give you that focus on producing a known line-up that just works (and as we all know, we have had issues with Egit just landing randomly in a release cycle). SR testing is much lighter than release testing from my experience. From: Ian Bull irb...@eclipsesource.commailto:irb...@eclipsesource.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Tuesday, 2 July, 2013 5:03 PM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] 6 month release cycle The schedule you propose is interesting Doug. Two things stand out -- Your december release only has a one SR. (There is no 8.3.2). The second thing is that you plan on maintaining your June (Kepler) contribution in Feb (Kepler SR2). This is fine, but this is the opposite of what others have done. EGit (and Mylyn too, I think) have released new versions with the SRs. I'm not going judge what's better, but I don't like the fact that they are different. For example, the February 2014 will potentially have the latest and greatest EGit and a maintenance release of CDT after a new release was just announced. Combine that with the milestone stream that will undoubtedly be moving forward and our users will be hit with a confusing set of available sites from which to find their software. Also, what version of the CDT will be available in the MarketPlace next February? I'm not picking on anybody here. I think this demonstrates that we need to do something regarding multiple releases per year, and I'm doing my best do understand the different constraints we have. Cheers, Ian On Tue, Jul 2, 2013 at 1:28 PM, Doug Schaefer dschae...@qnx.commailto:dschae...@qnx.com wrote: Thanks Ian, to answer your questions: We do expect both releases to be the same quality and vendors will build on both, especially those vendors who need and are likely contributing the new features. We would build the mid-term release on the June platform. Although, we would love it if the platform released on the same cadence since a lot of what we need requires changes to both (project/build, debug/launch). Not to mention any serious contribution to cleaning up the Eclipse Platform UI to improve look and workflows that would benefit everyone, but that's a whole other set of issues. Both releases require their own ramp down so I'm not sure the M's would line up with the train properly. But I haven't looked at that yet. We do acknowledge that we need to spin the Eclipse C/C++ IDE package every six months as well to ensure our objective of getting users the new features faster is met. And the marketing along with that would certainly help get the word out that a new release is available. From: Ian Bull irb...@eclipsesource.commailto:irb...@eclipsesource.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Tuesday, 2 July, 2013 4:08 PM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] 6 month release cycle One of the things we need to understand is what do we want from a release train? 1. Is it simply a release of the latest and greatest stuff Eclipse has? 2. Is it a set of plugins / components that are known to 'work together'? 3. Is it a co-ordinated marketing exercise? 4. Is it a snap-shot in time of what we have? 5. Is it something else? There is nothing wrong with components doing their own release and coming together 1+2 times a year (release plus SRs). In this case the latest and greatest are in the SR0, SR1 SR2. We could also approach this from a two-stream perspective. Latest and greatest is in the Milestones, and the SR0, SR1 and SR2s are the LTS versions. Both of these will work, but I don't think we should mix match approaches. I'm sure with 71 projects in the release train, we'll arrive at 71 different meanings for the train. Doug, in the case of CDT, could you consider M4 M7 your 'releases' (after a few rounds of RCs of course)? What version of the platform do you want for your mid-term release (i.e. will Dec 2013 build on Kepler or Luna)? Do you expect / need marketing support for both releases? Do you expect both releases to be of the same quality (will vendors build on both)? Just a few more questions
Re: [cross-project-issues-dev] Kepler's final staging repository is complete
What Denis said. +1 From: Denis Roy denis@eclipse.orgmailto:denis@eclipse.org Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Thursday, 13 June, 2013 3:16 PM To: cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Kepler's final staging repository is complete I don't mean to belittle either issue (or, be hard on anyone personally) ... but ... as a release engineer, I am too aware of the many things that can go wrong with a last minute respin and the risks of making things worse. On which day does last minute begin, as we are 13 days away from the release? As a casual observer I'm puzzled by the test early, test often, fix nothing mantra. Does today's RC somehow become null and void if a respin is made and serious problems arise from it? ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] GEF Version Numbers
So much of what we can do as a community depends on trust. I'm having trouble understanding how the GEF community went for over four months with an unreleased version in our pristine simultaneous release repository without anyone noticing, especially through the SR1 and SR2 release cycles when everyone is expected to test their contributions to it. Sent from my BlackBerry 10 smartphone. From: Alexander Nyßen Sent: Saturday, February 23, 2013 4:44 AM To: Cross project issues Reply To: Cross project issues Subject: Re: [cross-project-issues-dev] GEF Version Numbers The 3.9.0M1 being included in SR1 seems to be an unchanged 3.8.0 with respect to bundles I meant 3.8.1 of course. Cheers Alexander Am 23.02.2013 um 08:06 schrieb Ed Willink e...@willink.me.ukmailto:e...@willink.me.uk: Hi Surely we must lose GEF 3.9.0 M5, so we must respin to pick up 3.8.2 that must be reversioned as 3.9.0 to succeed 3.9.0M1 in SR1? Then 3.10.0 for Kepler. [When this is all over, can we have a clearer policy on maintenance releases being maintenance releases, with some aggrcon tooling that diagnoses maintenance version consistency? Seems like this could have avoided both the EGIT and GEF problems.] Regards Ed Willink On 22/02/2013 23:41, Konstantin Komissarchik wrote: Alexander Nyßen wrote: GEF 3.9.0 M1 was included in SR1 instead of 3.8.1 (which - as far as I remember - still contained the 3.8.1 bundles, only the feature versions were incremented at that time) [snip] 3.9.0 M5 is now used instead of 3.8.2 in the SR2 (which actually contains 3.9.0 bundles) The situation in SR2 is far more severe than what happened in SR1. If SR2 respin is done to pick up the correct GEF 3.8.2 release, then users with GEF installed from SR1 repo will not be able to upgrade GEF, but at least no one will be running with pre-release code. Pick your poison. - Konstantin From: cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Doug Schaefer Sent: Friday, February 22, 2013 3:32 PM To: cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org; 'Cross project issues' Subject: Re: [cross-project-issues-dev] GEF Version Numbers If Ian is correct then SR1 already shipped a 3.9 milestone. Bizarre as that seams, that ship already sailed. Sent from my BlackBerry 10 smartphone. From: Konstantin Komissarchik Sent: Friday, February 22, 2013 5:55 PM To: 'Cross project issues' Reply To: Cross project issues Subject: Re: [cross-project-issues-dev] GEF Version Numbers Frankly it’s rather scary that SR2 will run on a milestone build of GEF. How much testing was there on this milestone to assure fitness for SR2? I know that I, along with others how build upon GEF, would rest easier if the GEF issue was also resolved in the respin. This is the last Juno service release. Let’s get this right, even if it takes a bit longer. - Konstantin From: cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Ian Bull Sent: Friday, February 22, 2013 2:50 PM To: Cross project issues Subject: [cross-project-issues-dev] GEF Version Numbers If GEF is (or has) released a feature with the version 3.9 and there is a new GEF release that contains additional API, then it should (must?) increment it's minor version to 3.10. If there is no new API between what's been released and Kepler, then I supposed that keeping 3.9 is ok, but really a increment in the service number should be included. (3.9.1?). I'm not sure how this affects all future releases? It means Juno SR0: GEF 3.8.0 Juno SR1: GEF 3.9.0 Juno SR1: GEF 3.9.0 (different qualifier) Kepler SR0: GEF 3.10.0 Kepler SR1: GEF 3.10.1 It's a little odd, but it allows adopters to target their dependencies. Otherwise, if we release 3.9.0 again with Kepler, adopters will have a hard time specifying if they want GEF Juno or GEF Kepler. Cheers, Ian On Fri, Feb 22, 2013 at 1:58 PM, Alexander Nyßen alexander.nys...@itemis.demailto:alexander.nys...@itemis.de wrote: The GEF and M2E bugs were also discussed. The M2E bug was perceived as a bug that could be addressed by the project's own update repo and hot fix process. The GEF issue is more complicated, can not be fixed by their own update site, exactly, since part of the damage already exists in SR1. We recommend to them to make their Kepler version be GEF 3.10, since various Juno versions will have some 3.9 and some 3.8; the differences in code are relatively minor, as I understand it, with the version change being the worst, and some adopters will have to work-around that, but it is feasible to live with it. Hmm, I am not sure whether I like that recommendation. GEF's release policy has always been easily traceable for all our clients, and with respect to our own update
Re: [cross-project-issues-dev] Wait ... don't release yet! ... delay one week, Friday 3/1
David can correct if I'm wrong here. But the decision was to actually remove Egit from the SR2 repo resulting in the Egit from SR1 getting picked up instead. Egit 2.2 wasn't considered. It's a pretty troubling situation. The community shouldn't be taking this lightly. Sent from my BlackBerry 10 smartphone. From: Oberhuber, Martin Sent: Friday, February 22, 2013 5:40 PM To: Cross project issues Reply To: Cross project issues Subject: Re: [cross-project-issues-dev] Wait ... don't release yet! ... delay one week, Friday 3/1 Thanks Matthias – So then in my understanding there is no contribution in Simrel outside egit itself, that would require egit-2.3 and thus the rollback should be fine. Using 2.2 seems preferable to me, to get the fix for bug 391377 that Chuck Bridgham has mentioned. Thanks, Martin -- Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River direct +43.662.457915.85 fax +43.662.457915.6 From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Matthias Sohn Sent: Friday, February 22, 2013 11:34 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] Wait ... don't release yet! ... delay one week, Friday 3/1 2013/2/22 Oberhuber, Martin martin.oberhu...@windriver.commailto:martin.oberhu...@windriver.com Kosta has a very good point here: moberhuber@build:/home/data/httpd/download.eclipse.org/releases/juno/201302220900mailto:moberhuber@build:/home/data/httpd/download.eclipse.org/releases/juno/201302220900 unzip -p content.jar | egrep 'unit id=|required.*eclipse..git' | grep -B 10 'required.*git.*2\.3' | less unit id='org.eclipse.mylyn.github.core' version='2.3.0.201302130906' required namespace='java.package' name='org.eclipse.egit.core' range='[2.3.0,2.4.0)'/ required namespace='java.package' name='org.eclipse.egit.github.core' range='[2.3.0,2.4.0)'/ […] unit id='org.eclipse.mylyn.github.ui' version='2.3.0.201302130906' required namespace='java.package' name='org.eclipse.egit.core' range='[2.3.0,2.4.0)'/ required namespace='java.package' name='org.eclipse.egit.core.op' range='[2.3.0,2.4.0)'/ […] unit id='org.eclipse.egit.mylyn.ui' version='2.3.0.201302130906' required namespace='java.package' name='org.eclipse.egit.core' range='[2.3.0,2.4.0)'/ required namespace='java.package' name='org.eclipse.egit.core.synchronize' range='[2.3.0,2.4.0)'/ That should be all dependencies onto egit-2.3. I think that egit.mylyn.ui comes from egit itself, but where does the mylyn github feature actually come from ? yes, egit.mylyn.ui is egit's mylyn integration and comes with egit mylyn github feature is the Mylyn GitHub connector which is part of the EGit contribution since it's developed in the EGit project. So if the EGit contribution is rolled back to SR1 this would include rolling back the Mylyn GitHub connector to 2.1, same holds true for 2.2.0 since all these features come in the same egit.b3aggrcon file. -- Matthias ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] GEF Version Numbers
If Ian is correct then SR1 already shipped a 3.9 milestone. Bizarre as that seams, that ship already sailed. Sent from my BlackBerry 10 smartphone. From: Konstantin Komissarchik Sent: Friday, February 22, 2013 5:55 PM To: 'Cross project issues' Reply To: Cross project issues Subject: Re: [cross-project-issues-dev] GEF Version Numbers Frankly it’s rather scary that SR2 will run on a milestone build of GEF. How much testing was there on this milestone to assure fitness for SR2? I know that I, along with others how build upon GEF, would rest easier if the GEF issue was also resolved in the respin. This is the last Juno service release. Let’s get this right, even if it takes a bit longer. - Konstantin From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Ian Bull Sent: Friday, February 22, 2013 2:50 PM To: Cross project issues Subject: [cross-project-issues-dev] GEF Version Numbers If GEF is (or has) released a feature with the version 3.9 and there is a new GEF release that contains additional API, then it should (must?) increment it's minor version to 3.10. If there is no new API between what's been released and Kepler, then I supposed that keeping 3.9 is ok, but really a increment in the service number should be included. (3.9.1?). I'm not sure how this affects all future releases? It means Juno SR0: GEF 3.8.0 Juno SR1: GEF 3.9.0 Juno SR1: GEF 3.9.0 (different qualifier) Kepler SR0: GEF 3.10.0 Kepler SR1: GEF 3.10.1 It's a little odd, but it allows adopters to target their dependencies. Otherwise, if we release 3.9.0 again with Kepler, adopters will have a hard time specifying if they want GEF Juno or GEF Kepler. Cheers, Ian On Fri, Feb 22, 2013 at 1:58 PM, Alexander Nyßen alexander.nys...@itemis.demailto:alexander.nys...@itemis.de wrote: The GEF and M2E bugs were also discussed. The M2E bug was perceived as a bug that could be addressed by the project's own update repo and hot fix process. The GEF issue is more complicated, can not be fixed by their own update site, exactly, since part of the damage already exists in SR1. We recommend to them to make their Kepler version be GEF 3.10, since various Juno versions will have some 3.9 and some 3.8; the differences in code are relatively minor, as I understand it, with the version change being the worst, and some adopters will have to work-around that, but it is feasible to live with it. Hmm, I am not sure whether I like that recommendation. GEF's release policy has always been easily traceable for all our clients, and with respect to our own update sites there is indeed no problem involved: we have released 3.8.0 and 3.8.1 on the GEF's releases update site properly and we intended do the same with 3.8.2 (which is the intended release for Juno SR2). Because of a missing upper version limit in the gef.b3aggrcon file it happened that GEF 3.9.0 M1 was included in SR1 instead of 3.8.1 (which - as far as I remember - still contained the 3.8.1 bundles, only the feature versions were incremented at that time) and accordingly 3.9.0 M5 is now used instead of 3.8.2 in the SR2 (which actually contains 3.9.0 bundles). Leaving 3.9.0M5 within the SR2 release repo is one thing (I can understand the councils decision, even if I would have liked it to be otherwise), but I don't like that this is going to affect all our future releases as well. Having said so, I would propose that with Kepler we will continue exactly as planned, i.e. ship our intended 3.9.0 release. All our bundles and features are properly equipped with qualifiers, so there should be no problem if the 3.9.0M5 in Juno SR2 is succeeded by the actual 3.9.0 release in Kepler. This way, the Juno SR1 and SR2 aggregator repos would be the only places that reflect the above mentioned inconsistency and from Kepler on, everything would be fine again (and we will not have to explain, where we lost our 3.9.0 release). Concerning the GEF releases site, I would like to go for the intended 3.8.2 release there, so clients can consume it from there if they want to, while the 3.9.0M5 is also available from our milestones site. Cheers Alexander Dr. Alexander Nyßen Dipl.-Inform. Software-Engineer Telefon: +49 (0) 231 / 98 60-210 Telefax: +49 (0) 231 / 98 60-211 Mobil: +49 (0) 151 / 17396743 http://www.itemis.de alexander.nys...@itemis.demailto:alexander.nys...@itemis.de itemis AG Am Brambusch 15-24 44536 Lünen Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- R. Ian Bull | EclipseSource
Re: [cross-project-issues-dev] Status and outlook for Final Juno SR2
Haven't seen a mail from David yet. So in hope, CDT has a rebuild to fix a CCE from bug 400747 that we just published. Thanks, Doug. Sent from my BlackBerry Z10. From: David M Williams Sent: Tuesday, February 12, 2013 2:51 PM To: Cross project issues Reply To: Cross project issues Subject: [cross-project-issues-dev] Status and outlook for Final Juno SR2 Its been a pretty quiet RC4 week! Just wanted to send a reminder that final contributions are due tomorrow, 2/13, 5 PM (with final EPP packages done by Friday). And then begins quiet week. While there is no specific document for Final Daze for maintenance releases, the release engineers among you should re-read http://wiki.eclipse.org/Juno/Final_Daze to be reminded of the concepts (e.g. leave builds/repos invisible until the release date, 2/22). Thanks, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Status and outlook for Final Juno SR2
Right. Forgot about that. Thanks, David. I'll start one. Sent from my BlackBerry Z10. From: David M Williams Sent: Wednesday, February 13, 2013 7:56 PM To: Cross project issues Reply To: Cross project issues Subject: Re: [cross-project-issues-dev] Status and outlook for Final Juno SR2 Always time for CDT. :) ... I don't see one starting on its own, though ... do you need to manually start one? (no change in b3aggrcon file) Or ... ? Was you note intended as request for me to manually start one? (Any simrel committer can start one, if you updated your repo, but not your b3aggrcon file). From:Doug Schaefer dschae...@qnx.com To:cross-project-issues-dev@eclipse.org cross-project-issues-dev@eclipse.org, Cross project issues cross-project-issues-dev@eclipse.org, Date:02/13/2013 07:33 PM Subject:Re: [cross-project-issues-dev] Status and outlook for Final Juno SR2 Sent by:cross-project-issues-dev-boun...@eclipse.org Haven't seen a mail from David yet. So in hope, CDT has a rebuild to fix a CCE from bug 400747 that we just published. Thanks, Doug. Sent from my BlackBerry Z10. From: David M Williams Sent: Tuesday, February 12, 2013 2:51 PM To: Cross project issues Reply To: Cross project issues Subject: [cross-project-issues-dev] Status and outlook for Final Juno SR2 Its been a pretty quiet RC4 week! Just wanted to send a reminder that final contributions are due tomorrow, 2/13, 5 PM (with final EPP packages done by Friday). And then begins quiet week. While there is no specific document for Final Daze for maintenance releases, the release engineers among you should re-read http://wiki.eclipse.org/Juno/Final_Daze to be reminded of the concepts (e.g. leave builds/repos invisible until the release date, 2/22). Thanks, [attachment unnamed deleted by David M Williams/Raleigh/IBM] ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Hudson failure
Yup. CDT failed too with a Hudson exception. Sent from my BlackBerry Z10. From: Greg Watson Sent: Friday, February 1, 2013 9:03 PM To: Cross project issues Reply To: Cross project issues Subject: [cross-project-issues-dev] Hudson failure For some reason Hudson has started failing. Anyone else seeing this? Greg Begin forwarded message: From: hudsonbu...@eclipse.org Subject: [ptp-dev] [Hudson] Build failed in Hudson: ptp-master-release #75 Date: February 1, 2013 7:28:14 PM EST To: ptp-...@eclipse.org Reply-To: Parallel Tools Platform general developers ptp-...@eclipse.org See https://hudson.eclipse.org/hudson/job/ptp-master-release/75/ -- Started by user gwatson Building remotely on hudson-slave1 Checkout:ptp-master-release / https://hudson.eclipse.org/hudson/job/ptp-master-release/ws/ - hudson.remoting.Channel@5e253843:hudson-slave1 Using strategy: Default Last Built Revision: Revision d36d8a3a57bd0a05c347fb723747c0c12d2bfd3b (origin/ptp_6_0) FATAL: cannot assign instance of hudson.EnvVars to field hudson.plugins.git.GitSCM$3.val$environment of type hudson.EnvVars in instance of hudson.plugins.git.GitSCM$3 java.lang.ClassCastException: cannot assign instance of hudson.EnvVars to field hudson.plugins.git.GitSCM$3.val$environment of type hudson.EnvVars in instance of hudson.plugins.git.GitSCM$3 at java.io.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2032) at java.io.ObjectStreamClass.setObjFieldValues(ObjectStreamClass.java:1212) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1953) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) at hudson.remoting.UserRequest.deserialize(UserRequest.java:178) at hudson.remoting.UserRequest.perform(UserRequest.java:98) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:283) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) -- This message is automatically generated by Hudson. For more information on Hudson, see: http://hudson-ci.org/ ___ ptp-dev mailing list ptp-...@eclipse.org https://dev.eclipse.org/mailman/listinfo/ptp-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] CVS access to Orbit
+1. Was trying to set things up for my contractor who's not a committer and ran into this problem as well. And I'm not sure how to install some of these things from the p2 repo since they don't have features. On 13-01-14 3:36 PM, Ed Willink e...@willink.me.uk wrote: Hi My understanding is that CVS has been preserved for Orbit, at least temporarily, but anonymous access has not. How am I expected to rewrite PSF fetches (for use by ordinary users) such as provider id=org.eclipse.team.cvs.core.cvsnature project reference=1.0,:pserver:anonym...@dev.eclipse.org:/cvsroot/tools,org.eclip se.orbit/lpg.runtime.java,lpg.runtime.java,v2_0_17/ /provider Regards Ed Willink ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] build.eclipse.org git.eclipse.org access
Nope, I just got in fine. Is your IP address blocked? Happens time to time. On 12-10-02 2:46 PM, Greg Watson g.wat...@computer.org wrote: We're not able to access build.eclipse.org or git.eclipse.org via ssh. Is anyone else seeing this problem? Greg ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Status and readiness for Kepler M1
Back to someone's earlier question, yes, for me this is a bit of a silent protest. CDT has never contributed to an M1 build. We're too busy with vacations or working on SR-1 of the previous release. That was fine because we were always enabled and picked up the final bits from the previous release. I'm not pleased by this, and yes it's late, but then that's why it shouldn't have been done to begin with (not so silent any more ;). :D From: Oberhuber, Martin martin.oberhu...@windriver.commailto:martin.oberhu...@windriver.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Wednesday, 22 August, 2012 9:17 AM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Status and readiness for Kepler M1 In fact I’ve enjoyed my vacation not checking Eclipse mailing lists recently :) I’m going to enable the tm.b3aggrcon and tcf.b3aggrcon as soon as my SSH access to Eclipse.org is back https://bugs.eclipse.org/bugs/show_bug.cgi?id=387782 Martin From: cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David M Williams Sent: Wednesday, August 22, 2012 7:10 AM To: cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: [cross-project-issues-dev] Status and readiness for Kepler M1 Still 26 projects not enabled for Kepler M1. Can some one explain to me what this is about? Some passive aggressive protest? Too many people take vacation all summer and don't even check Eclipse mailing lists? Are projects just indecisive and think a commitment now means it is a written in stone promise (which is never the case). I know one or two people have mentioned they have special problems that will likely prevent participation in M1, but, If I hear nothing, I'll assume the remaining 24 or so are dropping out, and will remove those files from the 'master' branch. For those projects to rejoin later will take an exception since there's a requirement for those participating to keep participating or else inform us all you no longer plan to. The M4 deadline only applies to branch new projects, others (in previous release) expected to be in M1. http://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Integrate_Early_and_Often I should emphasize, if people do not want to be in sim. release, that's fine. It is a voluntary choice, and does take some amount of extra work. So, it doesn't mean you are a bad project or anything if you decide not to. But, it is only common courtesy to keep us informed explicitly. Thanks, amp.b3aggrcon - org.eclipse.simrel.build cdt.b3aggrcon - org.eclipse.simrel.build dltk.b3aggrcon - org.eclipse.simrel.build emf-query2.b3aggrcon - org.eclipse.simrel.build emft-ecoretools.b3aggrcon - org.eclipse.simrel.build emft-eef.b3aggrcon - org.eclipse.simrel.build emft-egf.b3aggrcon - org.eclipse.simrel.build emft-emffacet.b3aggrcon - org.eclipse.simrel.build epp-mpc.b3aggrcon - org.eclipse.simrel.build gmp-gmf-tooling.b3aggrcon - org.eclipse.simrel.build gyrex.b3aggrcon - org.eclipse.simrel.build jwt.b3aggrcon - org.eclipse.simrel.build mat.b3aggrcon - org.eclipse.simrel.build mdt-modisco.b3aggrcon - org.eclipse.simrel.build mdt-papyrus.b3aggrcon - org.eclipse.simrel.build mft.b3aggrcon - org.eclipse.simrel.build mylyn-docs-intent.b3aggrcon - org.eclipse.simrel.build pdt.b3aggrcon - org.eclipse.simrel.build rap.b3aggrcon - org.eclipse.simrel.build recommenders.b3aggrcon - org.eclipse.simrel.build rtp.b3aggrcon - org.eclipse.simrel.build scout.b3aggrcon - org.eclipse.simrel.build soa-bpel.b3aggrcon - org.eclipse.simrel.build soa-sca.b3aggrcon - org.eclipse.simrel.build tcf.b3aggrcon - org.eclipse.simrel.build tm.b3aggrcon - org.eclipse.simrel.build ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Migrating SimRel files this weekend to Git
Kepler should work with our Juno bits. In the past those were picked up automatically. I may have missed it, but is that no longer true? From: Greg Watson g.wat...@computer.orgmailto:g.wat...@computer.org Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Tuesday, 7 August, 2012 2:12 PM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Migrating SimRel files this weekend to Git David, We're dependent on CDT, so if I re-enable PTP it will generate a validation error. Do you want me to go ahead and enable it anyway, or wait until CDT enables theirs? Greg On Aug 7, 2012, at 10:23 AM, David M Williams wrote: The re-enable part is in the b3aggrcon file. There is now an enabled=fasle attribute for your contribution (in master branch) that you have to remove, commit, and push. Not sue what the status of the kepler flag is for simultaneous release in the Portal. AFAIK, the EMO is planning to roll-out their new Portal soon and I am assume that will all be handled then. The re-enable contribution is independent of that. (They could be made related ... but ... not sure anyone is thinking that far ahead). Thanks! From:Ed Merks ed.me...@gmail.commailto:ed.me...@gmail.com To:David M Williams/Raleigh/IBM@IBMUS, Cc:dennis.hueb...@itemis.demailto:dennis.hueb...@itemis.de Date:08/07/2012 03:30 AM Subject:Re: [cross-project-issues-dev] Migrating SimRel files this weekend to Git David, I'm not sure what I need to do to reenable EMF and XSD from the referenced bugzilla. I went to the portal to manage modeling.emf.emf, but I don't see Kepler in the choices: Mail Attachment.png Regards, Ed On 07/08/2012 1:56 AM, David M Williams wrote: Ok, all done The main changes were in http://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build Which itself was renamed from previous Juno specific version (Seems things are constant and steady enough to justify one document for both Juno and Kepler). If I've missed anything (or, anything unclear) let me me know. Most important, in the master branch (for Kepler), I have disabled every contribution and will require projects to re-enable themselves as a sign they are intending to participate in Kepler (See bug 365738). The bad news is there is a large order effect here. For example, EMF and GEF must re-enable themselves before WTP (or nearly anyone else) could correctly aggregate. The good news is that I put an early warm-up I build in for Eclipse and Equinox (and, yes, enabled them) and from some quick checks, it appears everyone still builds with the Platform's Kepler M1 (at least, as of right now, with warm-up) so ... the point is ... many low level projects such as EMF or GEF could likely re-enable themselves quickly before any new contributions were made/ready, thereby enabling your consuming projects to re-enable themselves too. Put another way, there is no reason to wait until your designated +n day to re-enable yourself, and if you do, it'd likely complicate getting M1 done. This complete the 5 steps outlined in my original note. Transition complete now on to business. Both Kepler M1 and Juno RC1 complete the same week (final contributions from 8/20 to 8/22). That will be a busy week, so anything that can be done early, even if done as warmup willl likely help that week complete on time. Thanks, From:David M Williams/Raleigh/IBM@IBMUS To:Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org, Date:08/06/2012 12:52 AM Subject:Re: [cross-project-issues-dev] Migrating SimRel files this weekendtoGit Sent by: cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org Just to keep all informed. I have migrated sim rel file to Git https://bugs.eclipse.org/bugs/show_bug.cgi?id=359240 And have the builds working at https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/ But have not yet update any related documentation or how to information, which I will be working on this week and post again when all done. https://bugs.eclipse.org/bugs/show_bug.cgi?id=386655 So, no need to worry about much till then, but ... reserve some time later in the week for worrying :) In the mean time, if you can't resist poking around :) remember that master of org.eclipse.simrel.build will be for Kepler and the Juno_maintenance branch will be for Juno SR1. As before, the resulting p2 repositories for Kepler staging will be http://download.eclipse.org/releases/staging while Juno SR1 p2 staging will be at http://download.eclipse.org/releases/maintenance Whew, From:David M Williams/Raleigh/IBM@IBMUS To:
Re: [cross-project-issues-dev] Juno RC3 content is ready
Since you're doing this so early on Friday, +1 for CPP. From: Markus Knauer mkna...@eclipsesource.commailto:mkna...@eclipsesource.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Friday, 8 June, 2012 9:35 AM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org, EPP Developer Mailing List epp-...@eclipse.orgmailto:epp-...@eclipse.org Subject: Re: [cross-project-issues-dev] Juno RC3 content is ready Juno RC3 EPP packages are now available at http://www.eclipse.org/downloads/index-developer.php Thanks and regards, Markus On Fri, Jun 8, 2012 at 3:17 PM, David M Williams david_willi...@us.ibm.commailto:david_willi...@us.ibm.com wrote: The repository has been updated (with RC3 content only) http://download.eclipse.org/releases/juno/ And the EPP Packages for RC3 will be available soon at http://www.eclipse.org/downloads/index-developer.php Thanks, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Hudson job keeps rebuilding
I'm seeing the same thing. The build page says there were No changes. Checking the polling log, I see: Started on Feb 26, 2012 3:01:15 AM Using strategy: Default [poll] Last Build : #255 [poll] Last Built Revision: Revision d39f64adfb1570f6be9f07a636d4d2a1bf781562 (origin/cdt_8_0) Last build was not on tied node, forcing rebuild. Done. Took 3.1 sec Changes found forcing rebuild is probably the key. Is everyone seeing the same? What does not on tied node mean? Doug. On Sun, Feb 26, 2012 at 12:21 PM, David M Williams david_willi...@us.ibm.com wrote: I know there was a problem where a Gerrit Plugin was triggering jobs (unrelated to Gerrit) but as far as I know, that was disabled/removed from the production Hudson system. (Sorry, don't know bug number). Plus, I had a case where URL Content Change trigger stopped working right, and those jobs were building over and over again, even though no content change (bug 363891 [1]). In the past, I've sometimes found it helps odd Hudson behavior to wipe out workspace, essentially resetting what ever is there. To get to that option, click on the job, click on Workspace (on left, upper part of page), which displays the workspace, but also reveals a Wipe out workspace option. I'm sure it is mostly superstitious behavior ... but has seemed to help in some cases. In any case, I'd encourage you see if any existing bugs are related to your observations [2] and if not, to open one [3] being sure to make note it is on Eclipse Infrastructure. Good luck, [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=363891 [2] https://bugs.eclipse.org/bugs/query.cgi?classification=Technologyproduct=Hudsonquery_format=advanced [3] https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Hudson From: Eike Stepper step...@esc-net.de To: cross-project-issues-dev@eclipse.org, Date: 02/25/2012 10:58 PM Subject: [cross-project-issues-dev] Hudson job keeps rebuilding Sent by: cross-project-issues-dev-boun...@eclipse.org Hi, One of my Hudson jobs, https://hudson.eclipse.org/hudson/job/emf-cdo-maintenance , repeatedly sees Git changes (SCM trigger) that do not exist. It always reports (a) Started by SCM change and (b) No changes. But then it triggers a build rather than just exit. I'm polling for SCM changes every 2 hours. That results in 12 unnecessary builds per day ;-( This strange behaviour started yesterday. Does anybody see the same behaviour? Cheers /Eike http://www.esc-net.de http://thegordian.blogspot.com http://twitter.com/eikestepper ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
