Bugzilla – Full Text Bug Listing
| Summary: | Which bundles are transfered to Platform? | ||
|---|---|---|---|
| Product: | [Eclipse Project] e4 | Reporter: | Jonas Helming <jhelming> |
| Component: | Tools | Assignee: | Jonas Helming <jhelming> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | Lars.Vogel, olivier.prouvost, tom.schindl, wayne.beaton, wim.jongman |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows NT | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 452061 | ||
|
Description
Jonas Helming
Question was raise on the mailing list if we want to include the bridge bundles. The bundle org.eclipse.e4.tools.emf.editor3x depends on the bridge, so until we change that, we need to include it. @Tom: The last commit on the *script.js bundle was almost 4 years ago. I am not aware of any users of this feature. I really liked it back then, because it was a nice show case for the power of the application model. However, I think it should not be moved along with the other tools, what do you think? As you have spent the work on this, I would remove it from the core tools feature only if you agree. IIRC this is not vital for the tooling and contribute through an extension point. removed ui.js and spy from core tools feature https://git.eclipse.org/c/e4/org.eclipse.e4.tools.git/commit/?id=77198308c2cbc5b150125134ab3b9d51819792d4 see also: https://bugs.eclipse.org/bugs/show_bug.cgi?id=452693 I am sorry but I missed this discussion (title was not really explicit and there is no mention of e4 in the text ! ), so I reopen this bug. The E4 spies (context spy, event spy, css spy) are very efficient tools to help to develop an E4 application. Not having them in the new E4 tools platform would be a big regression and would not help people to adopt this new framework. The live editor is considered as a spy (it depends on tools.spy) and is opened in the specific E4 spies window. It is very useful to understand and control the model during application running. The context spy is the same to control the injection contexts and understand what is happening with your injections. Event spy is interesting to get information about events, and the CSS spy is a 'must have' to find the right CSS code to write in a css file. Even if we decide to not move a certain bundle, it does not mean that we deprecate the those components, they can still be installed from the e4 site like before. So I would not call this a regression. Additionally, we can move other things at a later stage. However, I am happy to discuss this. For me the main motivation to graduate the core tools is to create a better user experience when developers get started with e4. I frequently get the feedback that users find it strange to go to an incubation project and install a tool, which is essential and should be used by everyone creating e4 applications. It leaves the feeling that e4 applications are still something exotic and I believe this has a negative effect on the adoption. The reasons for me to initially not add the spies to my propose list of bundles were: - They are currently not part of the "core" feature, so the user has to install them explicitly at the moment, too. (not really a reason, but more a hint) - The spies are useful, but not "essential" to create e4 applications. IMHO it is acceptable for users to install those tools if they want to use them. You could compare the core tools to JDT (essential) and the spies to something like checkstyle (usefule, but optional) - The live editor you have mentioned is actually not a core tool, too. As it recently caused some issues in the IDE, I would consider to remove it from the list of moved bundles - For CSS in particular: I think you need to install something additional anyways to work with CSS (i.e. a CSS editor) - I wanted to keep the number of moved bundles as small as possible for the first step. Graduating the bundles will create additional work. Are you willing to take over the graduation work for the spy components? Removing the spies from an existing feature without replacement is a bit -1 from me. I'm fine with moving the spies to their own feature. Such removals will affect our users, therefore we must explicitly announced and discuss them on the e4 mailing list. In this particular example several users I know will be affected if the upgrade their tooling. That is also a big -1. I suggest we create a separate bug report for this planned change, I did not expect that this "discussion bug" would result in any remove commits hence I also missed the commit in the history view. A commit called "Bug 445742 - Which bundles are transfered to Platform?" is not telling what happened here. I reverted the change with http://git.eclipse.org/c/e4/org.eclipse.e4.tools.git/commit/?id=46e94e5bd34d29fcd79856605cb82d7bc08828da Jonas, please open a new bug for this change. IMHO to remove the spies from core, we need a new spy feature. The .js can IMHO be removed from all features, but others might need to it. Once opened please announce on the e4 mailing list so that interested parties can comment. We can have the e4 core tools and an 'optional' feature to be installed. Yesterday I had a consultancy on skype (we shared the screens), and I asked my customer to open the context spy to understand what was wrong... Without it, it would have been not possible to find the problem (actually he set values in a new OSGi context instead of using the e4.ui.workbench context)... Spies are mandatory to understand and develop with E4. Could you imagine to develop and test your application without them ? If you have any problem you will have to install it..(this is why I said 'optional' between quotes)... So it should be proposed, in a separate feature and not in a feature for each one which is to complicated. (In reply to Olivier Prouvost from comment #8 > So it should be proposed, in a separate feature and not in a feature for > each one which is to complicated. Not sure if I understand your proposal correctly but I think you are suggesting one new feature for all spies. +1 for this proposal from me. Yes exactly ! We can move the 4 spies feature into only one. The future spies (bundle spy for instance...), will be added in this feature in the future. To add to this discussion, I agree with Jonas that the spies should not be moved to platform.ui. These are tools are should stay in e4 or be moved to PDE. (In reply to Olivier Prouvost from comment #10) > We can move the 4 spies feature into only one. Can you open a bug for this and announce it on the e4 mailing list. We (vogellacompany) have created a preference spy and are happy to contribute this one to the new feature. Lars, the bug #453528 is created. So if I understand, the actual e4 tools project will only contain the spies and nothing else after the migration ? (In reply to Olivier Prouvost from comment #13) > So if I understand, the actual e4 tools project will only contain the spies > and nothing else after the migration ? That is for us to decide. I think Jonas would like to migrate only the e4 wizards and the editor. That would be fine for me. @Lars: I think there was a mistunderstanding, the spies have not been part of the core tools feature before. The only bundle I removed is the common spy bundle. This bundle itself does not provide functionality (at least afaik). There are two dedicated features for the event spy and the context spy already. They also contain the core spy bundle, so it does not need to be contained in the core feature. If you agree to that I kindly ask you to apply the change again. And yes, it is correct, that I would favor to only move the core tools without the spies for now, because of the reasons I described. Ok.. Did you see that emf.live.editor depends on e4.tools.spy ? It will be a problem if you want to remove the e4.tools.spy from the core. The e4.tools.spy provides only 2 things : the spyPart extension point and a processor to process it. Actually the live editor is also the model spy. If you want to definitively remove the tools.spy from the core it is possible but there are 2 things to do : 1. Cut the spy part extension in the live.editor and the dependency to e4.tools.spy 2. Create a new plugin e4.tools.modelSpy depending on emf.live.editor and e4.tools.spy and restore the spyPart extension in. This solutions would separate definitively the spies from the core and identify officialy the 'modelSpy'. @Olivier: Thank you for pointing this out, I was indeed not aware of that. I like the idea of a dedicated spy feature, I have created a BR for it: https://bugs.eclipse.org/bugs/show_bug.cgi?id=453591 I will announce it on the mailing list, too. So the decision, which should be done here is still, whether the spy feature is moved to platform.ui, for me -1 for now. Added a dedicated bug for the liveeditor.js feature: https://bugs.eclipse.org/bugs/show_bug.cgi?id=453921 Are we getting to a conclusion here? Nobody else has commented, so I think it is us three who are currently interested in this. My suggestion is: 1. Split the core tools and the spy into separate features see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=453921 https://bugs.eclipse.org/bugs/show_bug.cgi?id=453528 2. Move only the core tools for now. We can still move the spy feature at a later point in time, if someone gets active on this. Ok for me... We will anyway have to install the spies if we use the core tools, so it will migrate anyway later. @Lars: do you agree, too? (In reply to Jonas Helming from comment #19) > 2. Move only the core tools for now. We can still move the spy feature at a > later point in time, if someone gets active on this. +1 OK I consider this a decision. Doing is tracked in: https://bugs.eclipse.org/bugs/show_bug.cgi?id=452061 Reopened to discuss the inclusion of the Model Spy (Live Editor). (In reply to Wim Jongman from comment #24) > Reopened to discuss the inclusion of the Model Spy (Live Editor). Wim if you want another bundle to to transferred you should open a new bug, move has been done already by webmaster. |