thanks for your efforts. the startup notification of scout is now removed for both mars and neon. matthias
From: [email protected] [mailto:[email protected]] On Behalf Of Christian Campo Sent: Mittwoch, 9. Dezember 2015 10:33 To: Cross project issues Subject: Re: [cross-project-issues-dev] Eierlegende Wollmilchsau Hi, I think this is a great effort and I highly appreciate that Ed took the time to start it. Coming with rules for some really basic sanity checks as they were already mentioned would be a great benefit. I think everyone understands that the plugins are not all from the same committer and have some differences but there should be a basic common understanding. Like Notifications (Scout) or preferences pages you cant leave without making changes. Doing tests automatic would be great but we need to start with deciding on rules first. Great effort (and great name :-) ) christian Von: <[email protected]<mailto:[email protected]>> on behalf of "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Antworten an: Cross issues <[email protected]<mailto:[email protected]>> Datum: Mittwoch, 9. Dezember 2015 um 10:11 An: Cross issues <[email protected]<mailto:[email protected]>> Betreff: Re: [cross-project-issues-dev] Eierlegende Wollmilchsau Hi, that sounds like an interesting exercise. Thank you for taking the time and the summarized findings, Ed. Maybe it's worthwhile to derive some minimal sanity checks from here and impose quality metrics for components on the release train? An integration test for the preferences would be helpful to ensure that users don't get trapped on a certain preference page. It's already bad enough if it's initially invalid but those things often refuse to ignore the error when a user tries to navigate to the next page. It would also be interesting to analyze why we run out of handles with a few dozen panels / preference pages and track the leakage down. Do all the views open without errors. Do the available perspectives make sense. Is the error log empty on a start? Is it empty when started without a network connection? A reasonable set of integrity checks can be easily done automatically and run on each distro that is built. Not so easy to test are the aesthetics, e.g. how views or perspectives look like. What should be possible to do though, is to detect if widgets are misaligned or icon sizes do not match the expectations in a toolbar / in the menu for example. At first it may appear to be harsh to reject bad citizens from the train / release repo, "just because" a feature breaks the preference page or makes the visual appearance of Eclipse inconsistent. On the other hand it's often one of the first things that users try when the IDE comes up for the first time: browse the toolbar and menu entries and look at the options and preferences. If we fail at that early stage, users will perceive Eclipse as broken, ugly or both. What do others think? Would this kind of automatic quality metric and integration test be valuable to improve the overall quality of Eclipse? And if we had such a test suite: What kind of measures can we take to fix the detected bugs? Best, Sebastian On Wed, 9 Dec 2015 at 07:54 Ed Merks <[email protected]<mailto:[email protected]>> wrote: Hi, We've created an all-in-one Eclipse product affectionately called Eclipse Eierlegende Wollmilchsau. For the linguistically challenged, it's the Eclipse Egg-laying Wool-milk-pig. Like the ultimate all-in-one farm animal, this Eclipse product can do everything because it installs everything on the release train. Unfortunately, it's not pretty. I've opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=483982 to track this issue. It's probably best that follow up discussions take place on this Bugzilla. To give it a try, use the Eclipse Installer, switch to advanced mode, and locate this product in the Eclipse.org Applications product catalog; typing "wol" in the filter will locate it quickly. Probably you'll want to pick the Mars version so that your bundle pool fills with useful things you might want to install some other time. We generate this product such that it installs all the categories on the release train, except the the RT category. Some immediate observations. The toolbar has a lot of buttons, some of them very large compared to the others. Unless you're blessed with a very wide monitor, they won't all fit on one line. Do we really need all these buttons in all perspectives? Open the Error log when the installation first starts. Clearly there are some ill behaved plugins. ECF contributes some things that don't work well. BPMN2 and Papyrus don't play well together. Nor do Eclipse FX and Papyrus. There's a battle for key bindings. Scout feels the need to inform the user of fact that it's started. Open the Progress view and note that there will be jobs that never will finish. What are these jobs trying to do? One reason we created this product is so we can test what's going on with all the preferences. There are certainly a great many of them. In fact, if you try to visit them all, you'll run out of SWT handles, so don't do that. With the latest version of Oomph, the preferences dialog includes an alert (little light bulb) down in the bottom left of the preferences dialog that allows you to initialize all preferences to their defaults; it will show only if you enable the preference recorder (via the button to the right of the help button). A great many preference pages change preferences just by virtue of visiting the page and hitting OK. With the preference recorder, this results in many preferences being recorded that you've never actually changed to be different from the default. Using the alert button, Oomph automatically visits all pages without recording any changes. It must periodically dismiss the preference dialog to ensure it doesn't run out of SWT handles. You might want to give that a try; please read the Help documentation of the "Preference Initialization" dialog. Some things to note afterward. How many preferences cause UI freeze report? Now that all bundles have been started, the jobs on the Progress view go crazy and they never ever finish. My computer fan comes on. It's not pleasant. Restarting the IDE helps put a stop to this. I believe it's the Linux tools doing this. Does it make sense to have Linux tools on my Windows machine? Probably not, but why is it an option if it makes no sense? I.e., can't the category requirements include filters to eliminate these choices? There are also several linux tools in the General Purpose Tools category, e.g., docker, changelog, and rpm. Are these really general purpose or Linux specific? Certainly RPM does not play nicely on my Windows box; jobs that apparently never finish, but work very hard doing goodness knows what... In the Error log you'll see many new errors. Papyrus is a big offender. Please someone on the Papyrus team, review what is going on with all your preference pages! They just don't work at all. Also note that Oomph logs warnings for all pages that come up in an invalid state initially. Once the user navigates to this preference page, they can't leave. No page should be initially invalid. Thym and Linux tools are offenders in this case. LDT, Data Tools, and BIRT should all have a look at this log because visiting their preferences result in errors. Also have a look at Help -> About Eclipse Platform -> Installation details and turn to the Plug-ins tab. Type "examples" in the filter. There are a great many of them! Does it make sense for people to install examples in their IDE? Aren't examples meant to be something I can easily add to my workspace (File -> New -> Example..) so I can see the source and play with it? Why are examples available for installation on the release train? The following example features are categorized as available for installation. I believe none of them should be. org.eclipse.equinox.p2.iu/org.eclipse.gef4.mvc.examples.source.feature.group org.eclipse.equinox.p2.iu/org.eclipse.gef4.zest.examples.source.feature.group org.eclipse.equinox.p2.iu/org.eclipse.emf.query.examples.feature.group org.eclipse.equinox.p2.iu/org.eclipse.emf.transaction.examples.feature.group org.eclipse.equinox.p2.iu/org.eclipse.emf.transaction.examples.feature.group org.eclipse.equinox.p2.iu/org.eclipse.emf.validation.examples.feature.group org.eclipse.equinox.p2.iu/org.eclipse.gef.examples.feature.group org.eclipse.equinox.p2.iu/org.eclipse.gmf.examples.runtime.feature.group org.eclipse.equinox.p2.iu/org.eclipse.graphiti.feature.examples.feature.group org.eclipse.equinox.p2.iu/org.eclipse.ocl.examples.feature.group org.eclipse.equinox.p2.iu/org.eclipse.bpmn2.modeler.examples.feature.group In other cases, the project SDK includes a dependency on the examples feature. I found EMF examples on the train, but I don't believe that EMF itself contributes them, so someone is generously doing that on our behalf. If you love Eclipse, please give the Eclipse Eierlegende Wollmilchsau some of your love. Or just ignore it, and accept the fact that Eclipse as a whole is an ugly pig. Regards, Ed _______________________________________________ cross-project-issues-dev mailing list [email protected]<mailto:[email protected]> To change your delivery options, retrieve your password, or unsubscribe from this list, visit 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.de<http://www.compeople.de> Vorstand: Jürgen Wiesmaier Aufsichtsratsvorsitzender: Christian Glanz Sitz der Gesellschaft: Frankfurt/Main Handelsregister Frankfurt HRB 56759 USt-IdNr. DE207665352 -------------------------------------------------------------
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
