Re: [cross-project-issues-dev] New UUID in Eclipse Platform
> > I may have missed this, but will the data be open as well, like the > download numbers are today? > > Doug. > I've not seen an answer to this, and I think information about how this data will be used, who it will be shared with and how it will be protected is essential. Since any plugin can read the UUIDs from the local machine, it becomes trivial to create a one-to-one mapping between them and a user's git credential, user name, etc... This is concerning. Cheers, Ian > ___ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] File server down?
I'm seeing this too. It's rather intermittent though. On Tue, Dec 1, 2015 at 12:16 PM, Pascal Rapicault <pas...@rapicorp.com> wrote: > When running the Egerrit build, I get a number of errors like the following > Caused by: org.eclipse.equinox.p2.core.ProvisionException: HTTP > Server 'Service Unavailable': > http://download.eclipse.org/tools/orbit/downloads/drops/R20150519210750/repository/content.xml.xz > > Is this something known? > > ___ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences
er has been deleted. Yes, I know > it's deprecated, but nevertheless it was once API before being > deprecated so deleting it is a breaking change. I don't recall there > being an announcement to begin deleting arbitrary deprecated API. > > In any case, I can't necessarily commit to making the necessary > changes. As such I can't commit to contributing EMF Core to Neon. > > I would suggest reconsidering the strategy of breaking APIs and most > certainly suggest any such actions ought to be announced and discussed > before such actions are taken. > > Regards, > Ed > ___ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > > > > > ___ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences
The reason it was not considered an API breaking change was explained to me in [1]. [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=475833#c15 Cheers, Ian On Sat, Sep 12, 2015 at 10:05 AM, Doug Schaefer <dschae...@qnx.com> wrote: > This affected CDT too. Luckily we were some what prepared and had one or > our crack committers fix it but it did force us to make a change to > continue on with Neon. > > So, I¹m not sure how this is not an API breaking change, deprecated or > not. I believe the Platform is going to have to ask the Planning Council > for an exception for this and get their approval. > > Doug. > > On 2015-09-12, 4:32 AM, "cross-project-issues-dev-boun...@eclipse.org on > behalf of Ed Willink" <cross-project-issues-dev-boun...@eclipse.org on > behalf of e...@willink.me.uk> wrote: > > >Hi > > > >TableTreeViewer removal was announced in > > > > > http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.platform.doc.i > >sv%2Fporting%2Fremovals.html > > > >But IPlatformRunnable is only announced as after June 2017 in > > > > > http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.platform.doc.i > >sv%2Fporting%2Fremovals.html > > > >so the discussed removal in > > > >https://bugs.eclipse.org/bugs/show_bug.cgi?id=475944 > > > >seems premature. > > > > Regards > > > > Ed Willink > > > >On 12/09/2015 09:05, Ed Merks wrote: > >> Hi, > >> > >> It was brought to my attention that > >> org.eclipse.jface.viewers.TableTreeViewer has been deleted. Yes, I > >> know it's deprecated, but nevertheless it was once API before being > >> deprecated so deleting it is a breaking change. I don't recall there > >> being an announcement to begin deleting arbitrary deprecated API. > >> > >> In any case, I can't necessarily commit to making the necessary > >> changes. As such I can't commit to contributing EMF Core to Neon. > >> > >> I would suggest reconsidering the strategy of breaking APIs and most > >> certainly suggest any such actions ought to be announced and discussed > >> before such actions are taken. > >> > >> Regards, > >> Ed > >> ___ > >> cross-project-issues-dev mailing list > >> cross-project-issues-dev@eclipse.org > >> To change your delivery options, retrieve your password, or > >> unsubscribe from this list, visit > >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > >> > >> > >> - > >> No virus found in this message. > >> Checked by AVG - www.avg.com > >> Version: 2015.0.6125 / Virus Database: 4419/10626 - Release Date: > >> 09/12/15 > >> > >> > > > >___ > >cross-project-issues-dev mailing list > >cross-project-issues-dev@eclipse.org > >To change your delivery options, retrieve your password, or unsubscribe > >from this list, visit > >https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > ___ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] jdt.core move to Java 7 BREE
Is this thread about what minimum BREE to use, or is it about announcing changes to this? I agree with most people here that Java 7 is a sensible minimum BREE for Mars, but I get the sense that this thread was more about how / where these changes are announced. Cheers, Ian On Wed, Mar 4, 2015 at 2:36 PM, Gunnar Wagenknecht gun...@wagenknecht.org wrote: Am 04.03.2015 um 13:53 schrieb Mike Milinkovich mike.milinkov...@eclipse.org: On 04/03/2015 4:15 PM, Martin Lippert wrote: I am not sure whether this “end of public updates” date reflects what is going on inside organizations. Oracle still offers support for Java6 until Dec 2015, and extended support for Dec 2018. http://www.oracle.com/technetwork/java/eol-135779.html#java-commercial-offerings Sure. And I'm also sure if you pay Microsoft enough money you can get support for Windows XP as well. That doesn't make it current. And we have a solution for this too -- LTS. If someone wants support for Eclipse for an older version of Java, then LTS would be the obvious recommendation. :) I guess we just need to come up with a common definition of what we mean by current version. I say: it should be every version receiving security updates public and free accessible for the community (committers, contributors and users). As of May 2015, Java 7 will fall out of that list. But that's just my two cents. -Gunnar ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Congratulations! Luna repository is available!
I just talked to Markus K (who is still in 'release stress mode'). Markus and Webmaster are updating the pages as I write this. On Wed, Jun 25, 2014 at 6:13 AM, Jacques Bouthillier jacques.bouthill...@ericsson.com wrote: I Just look at eclipse.org to download LUNA, but still show Kepler. Jacques *From:* cross-project-issues-dev-boun...@eclipse.org [mailto: cross-project-issues-dev-boun...@eclipse.org] *On Behalf Of *David M Williams *Sent:* June-25-14 8:55 AM *To:* cross-project-issues-dev@eclipse.org *Subject:* [cross-project-issues-dev] Congratulations! Luna repository is available! Markus and I have flipped on the Luna repository so the final release bits are now visible and available to the world. The EPP packages will be visible soon, if not already. Feel free to make your own sites visible, and make your own project announcements. (My own little sanity test seemed quite fast, I assume due to repositories being well mirrored and due to a well tuned infrastructure, thank Denis and team!) And thanks to all you projects teams for your cooperation and participation in this ninth annual Simultaneous Release. Well done! ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource ___ 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 home page now points to Luna
That menu item (downloads) always points to the the general downloads area, which always has the latest release. If you look at the Helios release, it does this too [1]. [1] https://www.eclipse.org/helios/ Here is a link to all the old downloads [2]. I guess you could raise a bug to change this, but for the 'average' person who stumbles upon an Eclipse release, we may want to point them to the latest stuff, but I'm sure we could debate that. :-) [2] https://wiki.eclipse.org/Older_Versions_Of_Eclipse Cheers, Ian On Wed, Jun 25, 2014 at 8:38 AM, Bob Brodt bbr...@redhat.com wrote: Hi all, I've noticed that the download link on the Kepler home page [1] still points to https://www.eclipse.org/downloads/ which now has the Luna stuff on it. [1] https://www.eclipse.org/kepler/ Robert (Bob) Brodt Senior Software Engineer JBoss by Red Hat ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource ___ 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] JFace Generics
On Sat, Aug 31, 2013 at 12:07 AM, Ed Merks ed.me...@gmail.com wrote: John, Please me be equally provocative. Hi everyone, before we declare thermonuclear war on each other, let's take a step back. John, there is no doubt that the success of Eclipse is a result of vibrant eco-system that has grown-up around the platform. The successful Eclipse projects that build on the platform are just as important as the core. I would argue that EMF (and Ed Merks in particular) is not simply an 'Eclipse Adopter'. In fact, I would say Ed has set the gold standard for Eclipse development. Ed, John is 100% correct that the project committers get the final say for all decisions. This is not just *how* it works, it's how it *must* work. Eclipse is a meritocracy, and John Arthorne has certainly earned the right to make any decisions regarding the core API -- and I don't think you could find anybody here that would disagree with that. John has gone above and beyond everyone else to ensure that the Eclipse Platform continually ships quality code, on-time. So, where do we go when two well-respected members of the Eclipse community have a different view of a core component that is shared between them? I wonder if the Architecture Council could play a role here? I don't think there is currently any precedent for this, but Wayne is re-working some of the EDP and maybe the AC should be given some power to actually 'architect' when different opinions emerge? Thoughts Finally, I want to call out Hendrik (the GSoC student working on this). I'm not in any position to judge your work this summer, but as a former GSoC student I couldn't imagine finding myself in a position such as this. Please don't let this little schism discourage you. Cheers, Ian ___ 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] Source code in simrel aggregate repo
aggregate repo Sent by:cross-project-issues-dev-boun...@eclipse.org -- I suspect that what has happened in at least some of the cases is that the requirements of the corresponding EPP package drove what was contributed to the simrel repository. A natural effect, but not ideal, since the user base for the simrel repo is more diverse in their requirements. Should this continue to be at project’s discretion or should contributing source to simrel repo be a requirement? I doubt that projects would object to contributing source if asked, but maybe it would be better spelled out up front. - Konstantin * From:* cross-project-issues-dev-boun...@eclipse.org [ mailto:cross-project-issues-dev-boun...@eclipse.orgcross-project-issues-dev-boun...@eclipse.org] *On Behalf Of *David M Williams* Sent:* Thursday, August 01, 2013 10:50 AM* To:* Cross project issues* Subject:* Re: [cross-project-issues-dev] Source code in simrel aggregate repo This has always been viewed to be the contributing project's decision. (Which ... is true in general ... some projects do not contribute ALL their features to common repo; such as perhaps not examples, perhaps not some of the rarer functions, etc.). I know for WTP, it was thought best to minimize download (so no source ... last I knew), since it was intended for people developing web apps ... not for people developing plugins for WTP. Hope that answers what you were asking. From:Konstantin Komissarchik konstantin.komissarc...@oracle.com To:'Cross project issues' cross-project-issues-dev@eclipse.org, Date:08/01/2013 12:58 PM Subject:[cross-project-issues-dev] Source code in simrel aggregate repo Sent by:cross-project-issues-dev-boun...@eclipse.org -- As part of working on the definition for Eclipse Ultimate Edition, I have discovered that a number of prominent projects do not contribute source to the simrel repo. Before I start opening bugs, is there prior context or discussion on whether or not source code should be in the simrel repo? Note that I am not asking whether source code should be in a particular package as that’s dependent on the user that the package is targeting. 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 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 -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource ___ 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
-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource ___ 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
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 to hopefully help drive the discussion :-) Cheers, Ian On Tue, Jul 2, 2013 at 12:49 PM, Igor Fedorenko ifedore...@sonatype.comwrote: 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.orgcross-project-issues-dev@eclipse.org https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-devhttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev __**_ cross-project-issues-dev mailing list cross-project-issues-dev@**eclipse.orgcross-project-issues-dev@eclipse.org https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-devhttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource ___ 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] Reminders for Juno SR2 final steps
Not the release day email I was expecting to wake up to, but I agree that a respin seems in order. In this case quality trumps deadlines. Cheers, Ian On 22 Feb 2013 06:19, Matthias Sohn matthias.s...@gmail.com wrote: 2013/2/22 Gunnar Wagenknecht gun...@wagenknecht.org Am 22.02.2013 11:33, schrieb Markus Knauer: - If I were a member of the EGit team, I would try to educate my users how to upgrade to 2.3.1 via wiki, blog posts, newsgroup/forum, mailing list, other channels... They are trying really hard. But honestly, would you download a software that has a disclaimer next to the download link which says hey, this is broken; you need to update afterwards? IMHO, in the current state of SR2, such a disclaimer has to be put somewhere on the download page. When it's really too late for SR2, the plan should be made for a SR2a. +1 what's the authority which can decide this ? Let me know when a decision is made, I'll standby to update our contribution for Juno SR2 or SR2a to EGit 2.3.1. -- 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
[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.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.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.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource ___ 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] Performance, 3.8 versus 4.2
was very surprised by this. Why is the 4.2 platform what's being fronted on the Eclipse download page when it's user experience and quality is lagging behind this much? Is it just me who have had this experience? Regards, Thomas Hallgren -- Message: 5 Date: Wed, 5 Sep 2012 06:29:22 -0700 From: Konstantin Komissarchik konstantin.komissarc...@oracle.comkonstantin.komissarc...@oracle.com To: 'Cross project issues' cross-project-issues-dev@eclipse.orgcross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Performance, 3.8 versus 4.2 Message-ID: 001201cd8b6a$76b74950$6425dbf0$@komissarc...@oracle.com001201cd8b6a$76b74950$6425dbf0$@komissarc...@oracle.com Content-Type: text/plain; charset=utf-8 Thomas, You are certainly not the only one seeing performance issues with 4.2. I go back and forth between 4.2 and 3.8 every day depending on the project I need to work on and the difference is quiet noticeable even on very fast hardware. The part I notice the most is the lengthy close all editors process. After drilling down into some task and opening a few dozen editors, clearing workbench of open editors takes several seconds. I can literally watch tabs disappear one by one. The same operation is practically instantaneous on 3.8. For stability, user experience and performance reasons, you will find that many third party distros have stayed on 3.8 for Juno. I don?t begrudge 4.x its growing pains. It is a complex technological shift with a lot of promise. What I find most troubling is the decision process that led to the use of 4.2 for Juno distros. When the decision was made, it was plainly evident that 4.2 wasn?t going to match 3.8 on any of the quality metrics. IDE users might have been ok with quality drop if 4.2 delivered compelling new functionality that you couldn?t get in 3.8, yet there is no tangible functional delta. The value of 4.x platform is for RCP developers and to certain limited extent for IDE plugin developers. Certainly not for IDE users. The refreshed look-n-feel has been touted as a big end user feature of 4.2, but the new look-n-feel itself has numerous issues that leave it looking like an unfinished project. Sadly, the user reaction that we?ve been seeing over the last several months has been entirely predictable. - Konstantin -- Kind regards, Mit freundlichen Grüßen Andrey Loskutov +Andrey: http://plus.google.com/u/0/113794713998126448910 ___ 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 listcross-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 -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource unnamed.gif___ 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] Performance, 3.8 versus 4.2
Was Juno a good point in time to introducing such a change? I say YES. Why? Because as the current situation shows us, ppl don't try things until they are forced to do so and that should we have chosen to wait until Kepler then the same discussion would have happen but in September 2013. And don't try the argument that you would have tried it. After all eclipse 4.1 was released in July 2011. I completely agree with Pascal on this point. If we didn't ship this year we would have simply delayed the problem. Of course, many people would have liked the small group of platform committers to have delayed the release until they managed to fix everything (in an open and transparent way, all for free), but that wasn't going to happen. To get the kinks worked out of a major release, we need your help! Also remember, the Eclipse platform team shipped both Eclipse 3.8 and 4.2 so we could transition more easily. However, there will not be an Eclipse 3.9, so if the 4.x platform is not useable for your needs, now would be the time to step up with some resources. Of course, many of the people who will follow this discussion are the ones up late at night, working on Eclipse on their own time. I'm not sure that asking this group to do more is the answer. But, if you're going to complain, please ask yourself: Did I do enough for this release, or am I getting out of the Eclipse platform exactly what I put in?. But more importantly than all this is the meta conclusion that the era of being able to take the platform for granted is over and that we are all going to have to pay more attention to it, roll up our sleeves and contribute. Maybe this is the wake-up call we all needed, or maybe it's simply another yeah, things need to improve and someone else better do it. :-| Cheers, Ian Pascal ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource ___ 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] Juno is GO!
Thanks for all the hard work Denis and congratulations to all! cheers, ian On Wed, Jun 27, 2012 at 6:01 AM, Denis Roy denis@eclipse.org wrote: As the subject says... Feel free to unhide your bits, announce your releases to the world and celebrate. Congratulations -- another release on time. You guys rock! Denis ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource ___ 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] p2 repositories ... we can do better
Sorry, a little late to this game, but another small thing. While David mentioned the use of packed jars, please keep the unpacked jars around too. We have found that the Java 7 pack/un-packer has changed (compared to previous versions), and we are having trouble processing pack.gz files on Java 7 Runtimes. If the un-packed jars are still around, p2 can fall back to these. Cheers, Ian On Mon, Mar 5, 2012 at 5:36 PM, Jesse McConnell jesse.mcconn...@gmail.comwrote: please don't let my 'silly' comment derail the conversation here...it was perhaps a careless word I threw out anything that improves peoples experience with p2 would be a good thing because right now for me it is still this black box that is a bit hit or miss in terms of what is in it, what comes out of it, and how its all organized I am sure people can say the same about maven central, but 5 minutes, a web browser and a bit of investigative spirit and clicking around can sort that out... by about the 5th jar file I have cracked open and sorting through MANIFEST.MF files...that is where the eye glazing comes in from my previous statement :) so by all means please continue improving p2 repositories! and if the eclipse-signing-maven-plugin is supposed to be doing anything from this conversation please bring that to my attention directly! cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Sat, Mar 3, 2012 at 07:02, Jesse McConnell jesse.mcconn...@gmail.com wrote: the eclipse-signing-maven-plugin takes care of some of it but reading over the original mail I sort of glazed over and didn't really pick up on where else it ought to have helped address things... so from my view the index and mirror files goop is stuff in tycho land if anyone picks up on a shortcoming of the signing plugin do chirp up and let us know...past that igor will likely know more on the p2 details, I still find it a bit silly. :) cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Sat, Mar 3, 2012 at 03:08, Marcel Bruch br...@cs.tu-darmstadt.de wrote: I'm evaluating how to make our repositories comply to these needs with our tycho build. Maybe some successful tycho user or tycho committer can comment on how to support pack200, p2.index files, and p2.mirrorsURL? To me it sounds like these configuration options should be part of the repository packaging but at least I haven't found them. Are there any options to switch on these things? Or is there a set of plug-ins to use that will do the trick? Thanks, Marcel ___ 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 -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource ___ 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] p2 repositories ... we can do better
Here is a link to the bug report: https://bugs.eclipse.org/bugs/show_bug.cgi?id=361628 cheers, ian On Mon, Mar 5, 2012 at 9:59 PM, Ian Bull irb...@eclipsesource.com wrote: Sorry, a little late to this game, but another small thing. While David mentioned the use of packed jars, please keep the unpacked jars around too. We have found that the Java 7 pack/un-packer has changed (compared to previous versions), and we are having trouble processing pack.gz files on Java 7 Runtimes. If the un-packed jars are still around, p2 can fall back to these. Cheers, Ian On Mon, Mar 5, 2012 at 5:36 PM, Jesse McConnell jesse.mcconn...@gmail.com wrote: please don't let my 'silly' comment derail the conversation here...it was perhaps a careless word I threw out anything that improves peoples experience with p2 would be a good thing because right now for me it is still this black box that is a bit hit or miss in terms of what is in it, what comes out of it, and how its all organized I am sure people can say the same about maven central, but 5 minutes, a web browser and a bit of investigative spirit and clicking around can sort that out... by about the 5th jar file I have cracked open and sorting through MANIFEST.MF files...that is where the eye glazing comes in from my previous statement :) so by all means please continue improving p2 repositories! and if the eclipse-signing-maven-plugin is supposed to be doing anything from this conversation please bring that to my attention directly! cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Sat, Mar 3, 2012 at 07:02, Jesse McConnell jesse.mcconn...@gmail.com wrote: the eclipse-signing-maven-plugin takes care of some of it but reading over the original mail I sort of glazed over and didn't really pick up on where else it ought to have helped address things... so from my view the index and mirror files goop is stuff in tycho land if anyone picks up on a shortcoming of the signing plugin do chirp up and let us know...past that igor will likely know more on the p2 details, I still find it a bit silly. :) cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Sat, Mar 3, 2012 at 03:08, Marcel Bruch br...@cs.tu-darmstadt.de wrote: I'm evaluating how to make our repositories comply to these needs with our tycho build. Maybe some successful tycho user or tycho committer can comment on how to support pack200, p2.index files, and p2.mirrorsURL? To me it sounds like these configuration options should be part of the repository packaging but at least I haven't found them. Are there any options to switch on these things? Or is there a set of plug-ins to use that will do the trick? Thanks, Marcel ___ 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 -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource ___ 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] Juno M4 status and outlook at end of +2 day ... calm before the storm?
Thanks Miles, I pinged the GEF leadership to see if this was just an oversight. I can certainly help ensure the Zest component works on Eclipse 4.x, but I can't personally commit to shipping the entire GEF project myself. Cheers, Ian On Tue, Dec 13, 2011 at 8:51 PM, Miles Parker milespar...@gmail.com wrote: IIRC, If it's not on the aggregator, we can't use it, and if it isn't in Juno it can't be part of aggregator. Besides AMP, which is comparatively small potatoes, there is GMF, Papyrus and all of the other graphical tools (including new ones like BPEL, etc..), so that would throw us all off. Aren't there some platform bits that consume Zest such as the dependency analyzer? (I guess that one is an add-on, now that I look.) I think the number one issue as far as maintaining for train would be whether GEF itself has dependencies on 3.7 only features, right? Otherwise it should be quite simple to update the build for e4. On Dec 13, 2011, at 8:33 PM, Ian Bull wrote: Wayne, What happens if a 'producer' doesn't sign up for the train? What I mean is, what happens if GEF -- which has historically been consumed by other projects -- is not part of the train? Will the previous years bytes be available? Is anybody who depends on GEF automatically 'off the train'? Cheers, Ian On Tue, Dec 13, 2011 at 5:14 PM, Wayne Beaton wa...@eclipse.org wrote: ** Hi Bob. You need to go to the project metadata in the portal and set the juno bit under the simultaneousrelease entry. Wayne On 12/13/2011 05:29 PM, Bob Brodt wrote: Hi Wayne, BPEL is hoping to be a new project this year, so just wanted to make sure we're on the list :) Thanks! Bob Brodt According to the participation list [1], we have 59 projects participating. Remember that I need you to flip the bit in the portal to show that you're participating. Sooner would be better than later. I did a quick run through of the project and have observed that the following projects are MIA from last year: - AMP - EMF Query - EMF Transaction - EMF Validation - GEF - GMF-Notation - Mobile Tools For Java (MTJ) - QVT Operational - Sequoyah The math doesn't add up, so I've made a mistake somewhere... I may have to write a query. More later. Let me know if you're having trouble. Wayne [1] http://eclipse.org/projects/releases/releases.php On 12/13/2011 05:06 PM, David M Williams wrote: Or, are you all just getting good at this? :) Everything seems to be going well with contributions to M4 aggregation, but thought I'd send a reminder there's only one day left to get contributions in for M4. We'll consider 5 PM Wednesday the deadline, unless someone says wait, almost ready. Thanks, ___ cross-project-issues-dev mailing listcross-project-issues-dev@eclipse.orghttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Wayne Beaton The Eclipse Foundation Twitter: @waynebeaton unnamed.png http://www.eclipsecon.org/2012unnamed.gifhttp://www.eclipsecon.org/2012 Q ___ 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 listcross-project-issues-dev@eclipse.orghttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Wayne Beaton The Eclipse Foundation Twitter: @waynebeaton 138x38.png http://www.eclipsecon.org/2012logo138x38.gifhttp://www.eclipsecon.org/2012 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
