Bugzilla – Full Text Bug Listing
| Summary: | [launch] [patch] Add Eclipse Product launch configuration type for true product configuration launches | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Gunnar Wagenknecht <gunnar> | ||||||||||
| Component: | UI | Assignee: | PDE-UI-Inbox <pde-ui-inbox> | ||||||||||
| Status: | NEW --- | QA Contact: | |||||||||||
| Severity: | enhancement | ||||||||||||
| Priority: | P3 | CC: | AndrewBachmann, apupier, curtis.windatt.public, ekke, hmalphettes, info, irbull, jeffmcaffer, kkreuzer, n.a.edgar, patrick, rolf.theunissen, Tod_Creasey | ||||||||||
| Version: | 3.6.1 | Keywords: | helpwanted, noteworthy | ||||||||||
| Target Milestone: | --- | ||||||||||||
| Hardware: | All | ||||||||||||
| OS: | All | ||||||||||||
| See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=408263 https://bugs.eclipse.org/bugs/show_bug.cgi?id=493618 |
||||||||||||
| Whiteboard: | |||||||||||||
| Attachments: |
|
||||||||||||
Created attachment 179468 [details]
product launcher patch
Updated patch which updated the launch shortcut to use the Eclipse Product launch config.
Introducing a new launch config adds more complexity. The Eclipse application config type isn't going to be deprecated any time soon. We aren't going to make having a product definition be a requirement for launching. Everyone wants to see a simpler launch config, but we need to support everyone's use cases. Feature based launch was an attempt to make things simpler for the 80% case, so perhaps we can do something similar here... 1) Add a new choice in the plug-ins tab drop down "Launch with plug-ins from a product definition". The UI would display a path to the product definition, supporting variables and a browse button. At launch time, the plug-ins would be chosen from the product definition, just as is done in Gunnar's patch. It is important to note that other settings such as the product/application to launch and arguments would not be based on the product. 2) Add a synch button to the plug-ins tab (only visible when the new option is selected). Pressing this button would wipe away the current launch config and replace the attributes with the values from the product config. This would save the user from having to go back to the editor and recreate the config if something was changed. 3) The launch buttons on the editor might need their behaviour tweaked. If there were multiple configs that pointed to the same product definition, a dialog could open to choose between them (supported by debug). If something was changed on the launch config and the button was pressed again, I don't know if the launch config should be overwritten or left as is (currently it leaves it as is). 4) To support a use case that Jeff has brought up, we could try and add support for junit launches. The plug-ins to launch would still be determined by the product definition, but additional plug-ins would be added based on the test class being launched, the test application, and any requirements they have. This would be extended to work for feature based launches as well. (In reply to comment #2) > Introducing a new launch config adds more complexity. Agreed. We need fewer, not more IMHO > 1) Add a new choice in the plug-ins tab drop down "Launch with plug-ins from a > product definition". > The UI would display a path to the product definition, supporting variables and > a browse button. At launch time, the plug-ins would be chosen from the product > definition, just as is done in Gunnar's patch. It is important to note that > other settings such as the product/application to launch and arguments would > not be based on the product. I was with you until the last sentence. It seems quite confusing to take the "content" of the product but not the configuration. Too many chances for error/confusion and not enough gain. > 2) Add a synch button to the plug-ins tab (only visible when the new option is > selected). Pressing this button would wipe away the current launch config and > replace the attributes with the values from the product config. This would > save the user from having to go back to the editor and recreate the config if > something was changed. Could be good. Perhaps "reload" or "refresh" would avoid the directional ambiguity of "sync" (i.e., people might thing that they change the launch config and that sync'ing would then change the .product). If reload/sync/... were implemented I suggest no fanciness. Simply toss the old one and make an complete new one to avoid any funky caching issues. > 3) The launch buttons on the editor might need their behaviour tweaked. If > there were multiple configs that pointed to the same product definition, a > dialog could open to choose between them (supported by debug). If something > was changed on the launch config and the button was pressed again, I don't know > if the launch config should be overwritten or left as is (currently it leaves > it as is). Yikes. Head hurts just thinking about it. > 4) To support a use case that Jeff has brought up, we could try and add support > for junit launches. The plug-ins to launch would still be determined by the > product definition, but additional plug-ins would be added based on the test > class being launched, the test application, and any requirements they have. > This would be extended to work for feature based launches as well. Perhaps adding a relation to a .product from a .launch supports this test scenario as well as some of the others. The basic notion of a PDE (OSGi, Eclipse, Junit plugin test, ...) launch could have an optional associated .product. If the product is there the set of bundles to run is those of the product plus potentially others derived from the launch type (e.g., test bundles). Launches could be configured to "autoupdate" the product part, user-initiated update or no update. This should give the behavior similar to the original suggestion as well as #2 and #4. (In reply to comment #2) > Introducing a new launch config adds more complexity. The Eclipse application > config type isn't going to be deprecated any time soon. We aren't going to > make having a product definition be a requirement for launching. Yeah, I figured an answer like this would be coming. However, from an implementation point of view, bringing all into the current launch config doesn't help with its the complexity either. > Everyone wants to see a simpler launch config, but we need to support > everyone's use cases. Feature based launch was an attempt to make things > simpler for the 80% case, so perhaps we can do something similar here... I think it's a question of scale out vs. scale up. Of course, everything can be integrated into the current launch config, but it won't get easier. > [...] It is important to note that > other settings such as the product/application to launch and arguments would > not be based on the product. I'm on the same line with Jeff here. I don't like fancy snyc/reload buttons that I have to press again and again and again. I really just want to point to a product configuration, optionally modify the workspace location and provide additional program/vmargs (eg. -console) and that's it. All other stuff is already defined in the product. There is no need to define it twice. > 4) To support a use case that Jeff has brought up, we could try and add support > for junit launches. Make sense. Anyway, I'm willing to work on a patch which brings this back into the Eclipse Application. There are some low-hanging fruits that are independent from the product story. For example, feature-based launched currently don't support included features at all, i.e. one has to specify them manually. Additionally, I added validation to warn if required included features aren't present/missing. Another validation I added is a warning when the product/application extension of the product/application being launch is not defined in the target system. For the story of true product launches I'd propose a "plug-ins" tab similar to the following. ---------------- Launch with: product configuration Configuration: ______________________________________________________ [ Browse... ] [ ] Automatically configure launch based on product configuration [ Configure Launch Now ] [ ] Validate product configuration automatically prior to launching [ Validate Now ] ---------------- When 'Automatically configure launch based on product configuration' is checked, several UI elements in the launch configuration will be disabled (grayed out) and annotated with an information explaining why it's grayed out together with a link to unset that option. The grayed out elements would be: Main tab: - Program to Run (read from product configuration) Plug-ins tab: - Default Start level and Default Auto-Start (read from product configuration) Configuration tab: - Configuration File (will always be generated based on product configuration) - Software Installation (can be detected automatically if p2 is present) Additionally, the Arguments tab will also show a hint that automatic configuration is enabled and that any argument entered here will be appended to the arguments specified in the product configuration. Thus, no fancy merge will be supported in "automatic" mode but a simple append. When 'Automatically configure launch based on product configuration' is not checked, the "Configure Launch Now' button might be used to apply a product configuration once. Optionally, a warning could show up that warns a user that this will "override" several aspects of the current configuration. But I'm not sure if this is necessary. While it is better to have a complete solution, my proposal was much smaller in scope. By only affecting the plug-ins tab, the code changes required were reasonable in size so there would be time to work on it in 3.7. It would have been an improvement on the current workflow (where you get no further synching between the definition and the config). What are the important parts to keep in synch with the product definition? Product to launch clearly (though this wouldn't be likely to change either), the plug-ins to run, their start levels, arguments? Jeff, there already is an association between a product definition and its configuration, it just isn't surfaced in the UI. We can certainly take advantage of the association in keeping things in sych. Gunnar, while it certainly is possible to have UI bits change/enable based on settings on other tabs, it isn't considered good style. There would have to be some explanation pointing the user to the plug-ins tab. At the same time, you want to be able to add additional arguments, which adds even more complexity. If you are willing to put time into improving this that's awesome. We just want to see a streamlined workflow for product developers without breaking the current workflow of tooling developers (or anyone not using a product file). (In reply to comment #5) > What are the important parts to keep in synch with the product definition? > Product to launch clearly (though this wouldn't be likely to change either), > the plug-ins to run, their start levels, arguments? IMHO all or nothing. Anything part way between will be confusing. The current situation is OK because you just know, the launch config is a snapshot of the .product and you (well I) expect that when I launch again from the .product, the corresponding .launch is basically rewritten. If I understand the direction here, somehow the .launch would be able to pull some values from the .product either automatically or on user request. Unless that pulling is the logical equivalent of the pushing that happens when the user runs the .product, there is a mismatch and people will confused. > Jeff, there already is an association between a product definition and its > configuration, it just isn't surfaced in the UI. We can certainly take > advantage of the association in keeping things in sych. Yup. My point was more around the model/concept for what is happening. If there was a "always pull from this .product" in a .launch then - Gunnar gets what he wants (?) - implementing JUnit launching tests in products means adding a few bundles in the .launch and specing the test class(es) to run - more goodness? The information about the base stuff (.product) and the stuff added by the launching context (e.g., junit info) are kept separate rather than having to hand craft 99% duplicate .launches for every scenario variation. > We just > want to see a streamlined workflow for product developers without breaking the > current workflow of tooling developers (or anyone not using a product file). Absolutely. There are many people who don't need or want .products. That seemed to line up with the idea of *optionally* being able to associate a .product with a .launch and have the .launch behaviour driven at least in part by the content of the .product. Created attachment 185094 [details] product launch patch This is an updated patch. It adds a new launch mode to the Plug-ins tab of the Eclipse application launcher. When selected a product configuration file must be specified which will be used for configuring the launch. The patch is for early review to get feedback. It needs further tweaking. Strings aren't externalized yet and the UI will likly not stay this way. It can be also installed into any Eclipse 3.7M4 from the following update site: http://eclipseguru.org/ The source is also available here: https://github.com/eclipseguru/pde-ui/tree/bug326059___launching-products (In reply to comment #5) > What are the important parts to keep in synch with the product definition? The patch so far pulls the following items from the product launch: * plug-ins to run * start levels * JRE (EE vs. VM) * program arguments * user arguments * config.ini template This is basically the "always pull from this .product" as proposed by Jeff. I think this is the best option. In addition to that it adds product validation to the launch: * required/included features present? It also includes a small improvement to the validation logic: * ignore non-resolving bundles because of wrong platform (os/ws/arch) The latter fixes the warning messages when launching a (shared) cross-platform launch configuration (whether plug-in, feature or product based) on different platforms. > Gunnar, while it certainly is possible to have UI bits change/enable based on > settings on other tabs, it isn't considered good style. Agreed. But I'm not really happy with touching the plug-ins tab only. For example, a users selects a product and then switches to the arguments tab and modifies the arguments. However, this is useless because they are pulled from the launch config on every start. > At the same time, you > want to be able to add additional arguments, which adds even more complexity. Good point. Right now the patch simply moves the synchronization logic from the LaunchAction to the launcher. I think there is also a better way of real integration with the launcher, i.e. instead of synchronizing the launch configuration on every launch we could improve the launcher code to directly read and compute the things from the product configuration. This leaves room for the improvements mentioned above. It doesn't make the launcher code simpler, though. > If you are willing to put time into improving this that's awesome. We just > want to see a streamlined workflow for product developers without breaking the > current workflow of tooling developers (or anyone not using a product file). Yes, backwards compatibility is an important issue as well. Curtis, do you think it's still possible to look at this for M6? Sorry, I can't make time right now to give this contribution a proper review. There are a lot of individuals cc'd on this bug, what are your thoughts? Does the patch work for you and solve a real problem you encounter? I have not actually tried the patch at this point. I think it will solve a very common issue for EclipseRT developers. We create our target platform by importing a p2 installation. There are multiple things that are not in synch between the PDE launch and the platform config and Gunnar documented them exhaustively. The one that are the most painful are the selection of bundles to start and the start levels. Being able to launch the product from PDE and reproduce exactly what we see when we launch it on the command-line is really fantastic. And for this we need the rest of the arguments to be in synch. Currently I workaround that by bundling a launch configuration file where I hardcode the parameters. I documented to everyone that once they have updated their target platform, theey must open the Run Config UI and reselect the required bundles by hand. I'll try to take the time to apply Gunnar's patch if that gives better chances to this to be committed and ready for 3.7 I'm very keen on improvements in this area. Thanks for taking the time. Some questions about the current patch (I've not reviewed but good answers here will motivate me to do so ;-) - Does the list of bundles from the product overwrite the list in the launch config or are they merged somehow? - What are the benefits (i.e., what can I do now that I could not do before) relative to just launching from the .product file? (In reply to comment #12) > - Does the list of bundles from the product overwrite the list in the launch > config or are they merged somehow? Complete override. No merge. That's why it's integrated into the tab. Once a product is select you'll no longer be able to select plug-ins on the launch config > - What are the benefits (i.e., what can I do now that I could not do before) > relative to just launching from the .product file? Lesser clicks, i.e. as a user you no longer need to open a product and click the link there. You can just use the run/debug shortcut. Also, the launch experience is more reliable. For example, if the product is based on features and validate prior launch is checked, you'll get proper validation that everything is in the target platform prior to launching. OK so then the launch config is a direct/exact match to the product definition and this enables normal "launch" workflows. That plus some validation improvements. Fair enough. Can you see an easy way to work in additional bundles. My main usecase is testing. I have a product and would like to add in tests and would rather not duplicate the product definition. I'm fine if this is/should be a separate bug but thought I would ask since you've been messing around in this area. One thought was product def bundles + ones selected in the launch config. If there is a conflict, the product def wins. Unfortunately we likely have to change the app that gets run as well... sigh. Created attachment 189599 [details] screenshot of product launch tab (In reply to comment #14) > Can you see an easy way to work in additional bundles. My main usecase is > testing. I have a product and would like to add in tests and would rather not > duplicate the product definition. I think that should be possible to integrated in the PDE JUnit launch workflow. Technically it isn't difficult at all to allow a launch configuration to override any settings from the product file. I'm just wondering about the UI for defining additional plug-ins/features. Currently a product configuration is select on the "Plug-ins" tab (see attached screenshot). If we move that to the "Main" tab (as another radio option in the "Program to Run" group) we could re-use the "Plug-ins" tab to allow customization of the plug-ins/features. We hast have to decide on the sync/merge behavior then. Interesting thought. I'm not sure if/how it would fit on the Main page and if that would be too much of a digression from the current model. As far as merge policy, my immediate usecase is bundles are additive, just wanting to add in the test bundles. I can see how this might get out of hand though. Need to change the app, and then maybe tweak the args, ... Not sure what to do but do know that users I see struggle with how to run Junit plugin tests if their app needs any sort of customization on the start levels or whatever... *** Bug 85279 has been marked as a duplicate of this bug. *** PDE will support this work, but we do not have the resources to implement it. It is important that the UI looks good and the workflow is easy to follow. *** Bug 279302 has been marked as a duplicate of this bug. *** *** Bug 358139 has been marked as a duplicate of this bug. *** This functionality obviously isn't critical but it would help remove one of the more confusing aspects of RCP development. I wrote a blog post last year that discusses why I tell all of my students to always run using the link on the product configuration editor. http://www.modumind.com/2012/11/08/rcp-best-practices-always-run-code-using-a-product-configuration/ Looking over the comments, I agree with Jeff that every single aspect of the product configuration should be used in the run config. I also think this should be regenerated every time so that the run config is always in synch with the product. My preference would be to add a "Run a product configuration" radio button to the "Program to Run" section on the "Main" tab. The logic would be exactly the same as what happens when you run using the link on the Overview page of the Product Configuration editor. Is that any more doable than the previously proposed solution? |
Created attachment 179460 [details] patch The current way of launching products has some usability issues. For example, if a product configuration is modified the launch config is not updated. Another issue is validation of missing feature for feature based products, i.e. there is no way to find out if the launch configuration is valid based on feature products. Additionally, what also bothers me is that every time I launch, a shared launch config is overridden so it appears dirty in the workspace and needs to be committed to SCM. The attached patch introduces a new launch configuration type. I decided to create a new one in order to get rid of all the legacy handling. At some point, Eclipse Application might be just deprecated. However, the way it is implemented currently would allow to merge it back into "Eclipse Application" type. But looking forward I'd like to introduce additional usability enhancements (read "simplify the launch configuration dialog"). For example, currently the plug-ins tab group is not disabled at all, because it's all managed through the product. There might be instead an option to modify the product. While I'm add it, I also did some fixes to validation in order to discover missing product/application extensions.