Community
Participate
Working Groups
Currently it is possible to pass arguments to the JVM that Eclipse runs in with the -vmargs option on the command line. The options given, however, aren't used when running a unit test or application; these start in their own JVM. The JVM's arguments can be set from the "Run..." option. It would be nice to have a way to configure a default set of arguments to the VM so that they don't have to be configured for every Run configuration individually. For example, it might be really nice to be able to pass something like this to every Run instance by default: -DproxySet=true -DproxyHost=foobar -DproxyPort=1080 (rather than having to set those up individually for every Junit class, etc)
Launching issue. Moving to JDT/Debug.
*** Bug 43621 has been marked as a duplicate of this bug. ***
Since different users seem to have different attributes they want to share/re- use between configs, I see this as a general request for launch config templates.
Marking as deferred. Currently, we do not have the resources to implement such a feature in 3.0.
*** Bug 46000 has been marked as a duplicate of this bug. ***
*** Bug 46435 has been marked as a duplicate of this bug. ***
*** Bug 47522 has been marked as a duplicate of this bug. ***
*** Bug 51999 has been marked as a duplicate of this bug. ***
*** Bug 52028 has been marked as a duplicate of this bug. ***
*** Bug 62590 has been marked as a duplicate of this bug. ***
*** Bug 72755 has been marked as a duplicate of this bug. ***
*** Bug 74092 has been marked as a duplicate of this bug. ***
*** Bug 77008 has been marked as a duplicate of this bug. ***
I have some config files and other resources stored in a directory that I have to add to the class path for all executables in my project. So, in addition to default arguments, I would like to tack on default classpath additions.
*** Bug 79453 has been marked as a duplicate of this bug. ***
This is one of those Idea features that I miss very much.
*** Bug 110770 has been marked as a duplicate of this bug. ***
Could this bug be considered for 3.2? It has quite a few duplicates and it would eliminate the need for various launch-kind-specific workarounds such as bug 45408 comment 4.
Not planned for 3.2, not enough time/resources.
There's another similar enhancement request: https://bugs.eclipse.org/bugs/show_bug.cgi?id=67585 Please vote for it as well.
*** Bug 136355 has been marked as a duplicate of this bug. ***
*** Bug 137731 has been marked as a duplicate of this bug. ***
*** Bug 89670 has been marked as a duplicate of this bug. ***
reopening
Note that you can workaround this by adding your specific VM arguments in the eclipse.ini file (as it is done for -Xmx and Xms) and append these VM arguments in your launch config while creating it (set the check-box "Append the VM arguments specified in the target's launcher INI file" in the "Launching Arguments" tab of the Plug-in Development -> Target Platform preference page).
This bug should really have a higher priority. Please consider for 3.5.
*** Bug 234400 has been marked as a duplicate of this bug. ***
*** Bug 240373 has been marked as a duplicate of this bug. ***
My bug 89670 got marked as a dupe, but I'm not sure that this entirely captures my enhancement request. I was asking that we break apart the options that: - Describe the application to be launched - Describe the input to that application - Describe the environment in which it is to be launched ...in which case the launch configuration itself would simplified to a choice of application, environment, and input. I'm not sure that providing a default set of VM arguments would entirely provide the functionality I'm looking for.
*** Bug 256005 has been marked as a duplicate of this bug. ***
Please consider this for 3.5.
Sorry, this is not on the 3.5 plan and it is too late for 3.5. Resources were never allocated to do the work. I believe this is a big enough work item/feature that it would have needed to be in the M5 "big" feature freeze.
Another possible requirement is to be able to create templates at different scopes - similar to preferences. For example, at user, project, and enterprise levels.
Created attachment 149582 [details] Core infrastructure First implementation of headless infrastructure to support launch configuration templates, with tests. The wiki has been updated with a design doc/use cases: http://wiki.eclipse.org/Debug/Plan/3.6/Launch_Templates
Any chance we could see and review a quick outside-in description of the UI before this is implemented? I'm still not sure this will address my use-cases for bug 89670, which asks that I be able to separate the settings that describe the program being launched, its environment, and its input... and then be allowed to mix-and-match programs, configurations, and environments. It's good to see some momentum here, but I assume that by the time this is fully coded, it will be to late to comment on the workflows.
My appologies. I see you referenced a wiki page that I somehow missed. Please disregard my request for more details.
Created attachment 152103 [details] patch. Work in progress. Hoewver, we've hit a snag as documented in the WIKI and on the mailing list. Since configurations can use the absence of an attribute to indicate data/trigger behavior, using a simple approach of copying attrbites from the template to the configuration does not work as expected.
Work on templates has been deferred. To properly implement/integrate this feature requires more UI work than originally understood. The stumbling block centers around the fact that the UI needs to be able to distinguish which launch attributes are included in the template and which are not (as well as being able to validate templates properly). Just leaving attributes blank is not sufficient to denote that an attribute is excluded, as empty attributes can actually be relevant in templates (to indicate default settings such as using a project default JRE). Thus, integrating this feature would require all launch tab contributors to contribute new UI for templates - our hope was to be able to re-use existing implementations with no/minimal changes from exiting implementations. As well, being able to integrate templates with launch shortcuts/configuration creation (for example, default template for project), requires changes in existing implementations. We simply don't have the resources available to implement this feature.
I understand that a complete solution is expensive, but would a partial implementation be possible? By the sounds of the comments, what people need is the ability to provide global JVM args. In my case I want to be able to say that all Java processes should start up with -Xmx1024m. Could a field be made available on a project where I could specify that? It's not a complete solution, but might cover a large portion of the requests. There would be the question of what to do if one of the JVM args is 'overridden' in a run target. I don't know how the JVM would respond to arguments like this: "-Xmx1024m -Xmx512m". I'd hope that it takes the last argument, but I haven't checked.
(In reply to comment #39) > I understand that a complete solution is expensive, but would a partial > implementation be possible? By the sounds of the comments, what people need is > the ability to provide global JVM args. In my case I want to be able to say > that all Java processes should start up with -Xmx1024m. Note that JREs already support VM arguments that get applied to all launches. You can add VM args to the JRE's "Default VM Arguments" text box available via: Preferences -> Java -> Installed JREs > Edit...
We are having the same need for templates but for the list of active plug-ins rather than just VM arguments (which can be taken care of by modifying the "Target Platform" in the PDE Preferences). For development we have some plug-ins installed (e.g. subversion) which definitely we don't want active when running the unit tests, and automatically created run/debug configurations for junit or SWTBot include "all workspace and enabled target plugins" so we need to manually edit the configuration every time.
>include "all workspace and >enabled target plugins" so we need to manually edit the configuration every >time. Why? Can't you simply disable the bundles in your Target Platform?
*** Bug 339196 has been marked as a duplicate of this bug. ***
Are there any plans to include this feature in one of the next eclipse releases? Because there is no possibility to change the working directory of new launch configurations automatically. I need this because I want to separate the launch folder from my workspace when I launch a Java application.
(In reply to Lars Briem from comment #44) > Are there any plans to include this feature in one of the next eclipse > releases? > > Because there is no possibility to change the working directory of new > launch configurations automatically. I need this because I want to separate > the launch folder from my workspace when I launch a Java application. We are not working on this, but as indicated, help will be appreciated.
Another way to implement this system would be to maintain a link between a launch config and its original template then to apply the following strategy when evaluating a config attributes: - if an attribute has no value registered, use the template value - otherwise use the value from the launch config. Obviously the idea would be to save the value of an attribute in the launch config only if it has been modified by the user (change of value, or change from value to null). This strategy would solve the problem presented in the comment #38 of the bug (https://bugs.eclipse.org/bugs/show_bug.cgi?id=41353#c38). By the way, this would also imply that a change performed in a template will be immediately propagated to all the related launch configs without any action required from the user if the user has not modified the properties impacted in the launch config. Additional impacts can be anticipated according to this strategy: - Disconnecting a config would simply break the link between this config and its template. A prompt could ask the user if he wants to copy the attributes of its original template or not. - Conversely, associating a config with a template would create this link. The "propagate" function could propose to the user to override the launch config values to the template ones. Finally, given the freedom offered to the developers to create launch config UIs, it seems impossible to implement a generic mechanism to distinguish the attributes overridden from the attributes defined by the template. However we could create an API facilitating the graphic differentiation of these attributes (basically a service defining whether an config attribute is overridden or not).
(In reply to Goulwen Le Fur from comment #46) This defines on the core level how it could be implemented, but I don't see how it addresses the UI work that is required to make this work, and the impact on existing launch tab implementations, as outlined in comment 38.
https://wiki.eclipse.org/Debug/Plan/3.6/Launch_Templates#Default_Launch_Configuration_Settings_.28Workspace.2C_Project_preferences.29 Talks about the back pointer to the original template in the Launch Configuration. As Dani said we still have lots of UI work to be done. I think the problem we are facing here is because we want the launch to be linked with the template and allow the propagation while allowing the change of values in config. How about an approach of "Launch Specific Settings " on the concept of "Project Specific Settings" and basically we remove the link from the template after copying the values if user wants to do local changes. Then the value change in template will not be propagated. If Launch is not set for "Launch specific Settings", all the values from template will be taken. Only Launch Config name change could be done without removing the link. There should be a provision for import/export of templates between work spaces.
My bug got marked as a duplicate of this, but this template thing seems to miss the heart of what I wanted to achieve with my bug. Any given launch configuration has three types of settings: - Those that describe the application itself (the thing that gets published to user machines). - Those that describe the environment the app will run in (stuff that may change between user machines - such as amount of RAM or what type of device it will run on). - Those inputs that are expected to be user-configurable (user-provided settings and input files). Right now, every combination of launch-related settings is lumped together and gets called a launch configuration. I think we should be able to configure applications, environments, and inputs separately. The launch configuration screen itself would then just have three settings: the application, environment, and input. General-purpose launch configuration templates are more low-level. They'd allow the user to create their own abstractions for launch configurations. Although it could provide the same degree of reuse among launch configurations if done correctly, doing so would require more work for the end user and it would complicate rather than simplify the launch configuration dialog.
(In reply to Stefan Xenos from comment #49) +1 I think the term "templates" is wrong for this feature. Most duplicate bug reports expect to "share" some settings and expect that they can change those for the existing launch configurations.
From our point of view, there is no generic way to solve the UI issue. Indeed, the launch config's mission is to realize a binding between a set of SWT controls (the launch config tabs) and a Map of configuration attributes without any kind of traceability link persisted anywhere. Given that, we see two ways to manage this problem: - First solution (in the continuity of the platform's spirit) is to provide a service that define if an attribute of a launch configuration has a specific value directly coming from the launch configuration itself or a value coming from its original template (e.g. ILaunchConfiguration#isAttributeFromTemplate(String)) attributeName). Project developers could use this service to distinguish the two kinds of attributes by a graphical hint. We could also provide a set of guidelines (icons, colors...) to specify how the state of a value should be displayed coherently across the Eclipse projects. As an example, if the value is inherited from a template, it could be in italic. - Second solution, create a brand new graphical API which should be used by the developers to create launch config UIs if they want to be compliant with the templates mechanism. Using this API, the launch config UIs could be able to distinguish attributes coming from the template and attributes setted by the user. By adopting the first solution, developers would be able to update their UIs to the framework whenever they want. Prior to such an update, the system would be functional but the UIs would not be able to present the different attribute states. The migration to the new template mechanism could be done smoothly over time. The second solution would require a lot of work for both the plateform and the developer side (since they would have to re-develop all their launch UIs). It would also be difficult to provide a graphical framework covering all the existing cases in the eclipse project so that the extension of this framework should be allowed. That's why, we think that we should implement the first solution. This would allow us to implement this template mechanism quite easily and quickly. We should also provide a first implementation for the JDT and the PDE projects to demonstrate this new feature for the other projets.
Dani, Sarika, Do you have any comments/concerns about Goulwen's proposal?
(In reply to Mikaël Barbero from comment #52) > Dani, Sarika, > > Do you have any comments/concerns about Goulwen's proposal? First solution looks ok.
(In reply to Mikaël Barbero from comment #52) > Dani, Sarika, > > Do you have any comments/concerns about Goulwen's proposal? If we introduce a new Core and UI concept that allows to inherit values, then this also needs to be provided as API on both sides. Providing some guidelines will not do the trick. We already have a big mess with our project settings where the user has no clue whether the value is taken from the project settings or from the workspace. Background: Once a project decides to use project settings the current defaults are put into a settings file within that project. Good. However, when e.g. JDT adds a new option that option is not stored in the settings file, which means the user will see, well, actually not see, where the value is coming from.
Indeed, we plan to provide an API on both sides (core and UI) for this mechanism. The API on the core side will be non-intrusive and directly operational for the projects, but the API on the UI side will require an implementation by the project developers. In order to avoid situations where the template mechanism would be used to create launch configs without the launch config UI being updtated (and so the situation you describe in the previous comment where the user has no clue from where an attribute value com from), we propose to make the template mechanism deactivatable (always generic, but deactivatable) and to deactivate it by default. So, if a project wants to offer its users the ability to define launch configs template, developers will have to explicitly activate this feature and so we think that, at the same time, they will update the UI of their existing launch configs. In order to validate and to provide examples for the this mechanism, we believe that the first implementation should activate the mechanism for JDT and PDE projects (and obvisously the implementation should update the launching configs of these projects). We are aware that the solution is not totally optimal because it requires an update from the Eclipse projects side, but we believe that it constitutes an interesting improvement for the platform and the activation of this functionality for the JDT and PDE projects would benefit already a good user base of Eclipse. Have you got extra-ideas to solve this issue Dani?
(In reply to Goulwen Le Fur from comment #55) > Have you got extra-ideas to solve this issue Dani? I'm fine that those who want to use the new feature will have to update their UI. What needs to be provided is a UI control that deals with how shared values are presented, so that a user can see whether it's shared or not, the user can turn on and off the sharing, and the user can go to the template and change the value in the template. Can you attach a UI mockup for how you would design such an UI? As already mentioned, I think template is not the best name for this, because usually a template is used once to create something, but that's not what we are talking about here.
I agree with Dani. The "template" association feels wrong. This may be a crazy thought. What if the approach is inverse? If I'm understanding this correctly, the idea is to introduce a "partially" shared launch configuration, where some (most?) attributes are shared and only a few are not shared "local". Instead for introducing a "template", what about adding "local" attributes to shared launch configurations? API wise this could look like: - add "getLocalAttribute" methods to ILaunchConfiguration - local attributes are never shared in a repository (new contract of ILaunchConfiguration) open questions: - would those methods just delegate to getAttribute methods if "isLocal" returns true? - is the same attribute key with different values allowed for local/regular attributes? Again, this might be just crazy if I'm understanding this wrong.
(In reply to Dani Megert from comment #56) > (In reply to Goulwen Le Fur from comment #55) > > Have you got extra-ideas to solve this issue Dani? > > I'm fine that those who want to use the new feature will have to update > their UI. > > > What needs to be provided is a UI control that deals with how shared values > are presented, so that a user can see whether it's shared or not, the user > can turn on and off the sharing, and the user can go to the template and > change the value in the template. Can you attach a UI mockup for how you > would design such an UI? > > > As already mentioned, I think template is not the best name for this, > because usually a template is used once to create something, but that's not > what we are talking about here. Hi, In addition, here is a wiki page to illustrate Goulwen's proposition: https://wiki.eclipse.org/Debug/Plan/Launch_Configuration_Templates Best regards,
(In reply to Axel RICHARD from comment #58) > Hi, > > In addition, here is a wiki page to illustrate Goulwen's proposition: > https://wiki.eclipse.org/Debug/Plan/Launch_Configuration_Templates > > Best regards, Is there any option to apply template to a selected set of configurations of the same type ? I saw option to apply them to all the configurations of the same type.
(In reply to Sarika Sinha from comment #59) > Is there any option to apply template to a selected set of configurations of > the same type ? > I saw option to apply them to all the configurations of the same type. No, there is no such option in the proposition but it is definitely a good idea. It could be interesting to have it.
I would get rid of the "Apply template to all configurations", it's a corner case. If you want to apply a template after launch configs have been created, you will want to do it on a subset of the launch configs. So, what about a new menu item on launch config items: "apply template". It opens a popup menu where you have the list of all available templates. This menu item should also appear when multiple launch configs of the same kind (Eclipse App, JUnit) are selected to let one applies template values to several launch configs at once. Agreed about the "template" name. What about "prototype" as in prototype oriented programming where we "delegate" / "shadow" values to / from the prototype? With such a naming, in the "template" tab of a "template", I would replace the name of the tab with "Prototype", and "Shared" with "Visibility". "Visibility" would be a checkbox: check would mean "public" (the value is accessible, and as such launch configs can delegates to it) and uncheck would mean "private" (the value cannot be accessed by launch configs). Same thing for the "template" tab of a launch config. Rename "Template" to "Prototype" and "Shared" to "delegate" (checkbox?). Of course, you should not be able to delegate to a private attribute of a prototype. For clarity, I would also add another column, "Launch config value" before or after "Template/Protoype value". It will make be easier to compare and understand which value is taken. It's unclear to me what is editable in these tabs. Is it only the "visibility" / "delegate" state? A table like this may not be the best way to represent such data then. Maybe a checkbox tree with multiple columns? Or at least put the editable field (ie the checkbox) as first column.
Thank your very much Mikaël for your propositions ! (In reply to Mikaël Barbero from comment #61) > I would get rid of the "Apply template to all configurations", it's a corner > case. If you want to apply a template after launch configs have been > created, you will want to do it on a subset of the launch configs. > > So, what about a new menu item on launch config items: "apply template". It > opens a popup menu where you have the list of all available templates. This > menu item should also appear when multiple launch configs of the same kind > (Eclipse App, JUnit) are selected to let one applies template values to > several launch configs at once. Ok, I will update the wiki page with your proposition. > Agreed about the "template" name. What about "prototype" as in prototype > oriented programming where we "delegate" / "shadow" values to / from the > prototype? > > With such a naming, in the "template" tab of a "template", I would replace > the name of the tab with "Prototype", and "Shared" with "Visibility". > "Visibility" would be a checkbox: check would mean "public" (the value is > accessible, and as such launch configs can delegates to it) and uncheck > would mean "private" (the value cannot be accessed by launch configs). > > Same thing for the "template" tab of a launch config. Rename "Template" to > "Prototype" and "Shared" to "delegate" (checkbox?). Of course, you should > not be able to delegate to a private attribute of a prototype. For clarity, > I would also add another column, "Launch config value" before or after > "Template/Protoype value". It will make be easier to compare and understand > which value is taken. I agree with your propositions, I will update the wiki page. > It's unclear to me what is editable in these tabs. Is it only the > "visibility" / "delegate" state? A table like this may not be the best way > to represent such data then. Maybe a checkbox tree with multiple columns? Or > at least put the editable field (ie the checkbox) as first column. The columns "Shared" and "Value" are editable. I don't understand your proposition with the checkbox tree. Could you explain it more precisely ? Meanwhile, I will update the wiki page with the "shared" column as first column.
New Gerrit change created: https://git.eclipse.org/r/92991
New Gerrit change created: https://git.eclipse.org/r/93140
New Gerrit change created: https://git.eclipse.org/r/93749
A first implementation of the launch configuration prototype mechanism has been implemented. A wiki page explains how it works: https://wiki.eclipse.org/Debug/Plan/Launch_Configuration_Templates A screencast has also been attached to show you how it works. You can also checkout the following contribution to test it: https://git.eclipse.org/r/92991 An example of prototypes has been implemented for PDE's "Eclipse application" types (https://git.eclipse.org/r/93140) and JDT's "Java application" types (https://git.eclipse.org/r/93749). Feel free to comment the patches or to comment on this bug about the mechanism. Thank you in advance!
Created attachment 267432 [details] LaunchConfigPrototype-ScreenCast
(In reply to Axel RICHARD from comment #67) > Created attachment 267432 [details] > LaunchConfigPrototype-ScreenCast Can't see any thing.
(In reply to Sarika Sinha from comment #68) > (In reply to Axel RICHARD from comment #67) > > Created attachment 267432 [details] > > LaunchConfigPrototype-ScreenCast > > Can't see any thing. It seems the video can't be read by a browser. Try to download it and it should be ok.
Hello, If someone wants to review (In reply to Axel RICHARD from comment #66) > A first implementation of the launch configuration prototype mechanism has > been implemented. > A wiki page explains how it works: > https://wiki.eclipse.org/Debug/Plan/Launch_Configuration_Templates > A screencast has also been attached to show you how it works. > You can also checkout the following contribution to test it: > https://git.eclipse.org/r/92991 > An example of prototypes has been implemented for PDE's "Eclipse > application" types (https://git.eclipse.org/r/93140) and JDT's "Java > application" types (https://git.eclipse.org/r/93749). > Feel free to comment the patches or to comment on this bug about the > mechanism. > Thank you in advance! Hello, Any review or comment would be appreciated! Thank you in advance
(In reply to Axel RICHARD from comment #70) > Hello, > > Any review or comment would be appreciated! > > Thank you in advance Yes, will be looking into the code and UI, I was able to download and play it.
I tried the JDT's Implementation for Java Application. I could create a new prototype, apply and unapply prototype but I don't see the Prototype tab and without that I could test and verify the scenarios of controlling the values being copied and checking out the behavior on changing/resetting the values later.
(In reply to Sarika Sinha from comment #72) > I tried the JDT's Implementation for Java Application. > > I could create a new prototype, apply and unapply prototype but I don't see > the Prototype tab and without that I could test and verify the scenarios I guess you wanted to say "I could *not* test..."
(In reply to Dani Megert from comment #73) > I guess you wanted to say "I could *not* test..." Yes :) I could not test!!!
Hello Sarika, Thank you for the test and the rebase. I tested on my side with an Eclipse Oxygen SDK RC2 and it works. Did you think to import both org.eclipse.jdt.debug and org.eclipse.jdt.launching in your workspace ? If you only have imported org.eclipse.jdt.launching, you'll not able to see the prototype tab. Best regards,
Sorry I meant "import both org.eclipse.jdt.debug.ui and org.eclipse.jdt.launching."
(In reply to Axel RICHARD from comment #76) > Sorry I meant "import both org.eclipse.jdt.debug.ui and > org.eclipse.jdt.launching." Is it a temporary restriction ? In normal situation we will have both imported in our workspace.
(In reply to Sarika Sinha from comment #77) > (In reply to Axel RICHARD from comment #76) > > Sorry I meant "import both org.eclipse.jdt.debug.ui and > > org.eclipse.jdt.launching." > > Is it a temporary restriction ? > In normal situation we will have both imported in our workspace. No it is not a restriction. If you look at https://git.eclipse.org/r/#/c/93749/ you will see that those two plugins have been modified. So if you want to test it, then you have to import both plugins.
I had both of them in my workspace.
(In reply to Sarika Sinha from comment #79) > I had both of them in my workspace. I tried to reproduce the case where it is possible to create a new prototype, apply and unapply prototype but don't see the Prototype tab. The only way I found to reproduce that is to close the org.eclipse.jdt.debug.ui project. So if this project is open in your workspace, I don't understand what is happening here. May be you could test with the PDE implementation (via https://git.eclipse.org/r/#/c/93140/) please ? Or may be it is a platform related problem ? What is your OS ? (Mine is OS_X) Best regards,
Sarika, did you manage to try the patches?
(In reply to Mikaël Barbero from comment #81) > Sarika, did you manage to try the patches? Yes, I was able to test it. I can see the Prototype tab now and played around a bit. Some questions - 1. I changed the value of Project Name in Launch config which was different from Prototype applied, but it does not get highlighted as mentioned in Prototype Tab. 2. Unapply is not very clear. Does it store history og the values before using Apply ? I used Apply and Unapply, but it did not revert me to the old Project Name.
(In reply to Sarika Sinha from comment #82) > 1. I changed the value of Project Name in Launch config which was different > from Prototype applied, but it does not get highlighted as mentioned in > Prototype Tab. I don't reproduce this behavior. When I set a new project name in a launch config that is linked with a prototype, then in the Prototype tab, the attribute 'Project name' is highlighted because its value differs from its prototype. Could you describe precisely the steps to reproduce this behavior please ? > 2. Unapply is not very clear. Does it store history og the values before > using Apply ? I used Apply and Unapply, but it did not revert me to the old > Project Name. 'Apply' button and 'Apply' contextual menu entry allow to link a launch configuration to a prototype. 'Unapply' button and 'Unapply' contextual menu entry allow to broke this link.
(In reply to Axel RICHARD from comment #83) > (In reply to Sarika Sinha from comment #82) > > 1. I changed the value of Project Name in Launch config which was different > > from Prototype applied, but it does not get highlighted as mentioned in > > Prototype Tab. > > I don't reproduce this behavior. When I set a new project name in a launch > config that is linked with a prototype, then in the Prototype tab, the > attribute 'Project name' is highlighted because its value differs from its > prototype. Could you describe precisely the steps to reproduce this behavior > please ? I created a prototype, applied the prototype on a configuration. Changed the project name and pressed Apply. Went to Prototype tab, No highlighting found. Attaching the screenshot. > > > 2. Unapply is not very clear. Does it store history og the values before > > using Apply ? I used Apply and Unapply, but it did not revert me to the old > > Project Name. > > 'Apply' button and 'Apply' contextual menu entry allow to link a launch > configuration to a prototype. 'Unapply' button and 'Unapply' contextual menu > entry allow to broke this link. Ok!!
Created attachment 268880 [details] Highlighting in Protype tab
I haven't looked at any detail yet, but want to mention that 'Unapply' is a bad/misleading name. We already have 'Revert'. Maybe use more specific names to link and unlink.
(In reply to Dani Megert from comment #86) > I haven't looked at any detail yet, but want to mention that 'Unapply' is a > bad/misleading name. We already have 'Revert'. Maybe use more specific names > to link and unlink. Thank you Dani for this first feedback. I agree and will change the buttons labels soon.
(In reply to Sarika Sinha from comment #84) > I created a prototype, applied the prototype on a configuration. Changed the > project name and pressed Apply. Went to Prototype tab, No highlighting found. > Attaching the screenshot. I'm sorry but I didn't succeed to reproduce this behavior. I don't understand why, when you test it, the change of an attribute doesn't highlight it in the prototype tab.
Created attachment 269092 [details] Steps for highlightling issue Attaching the gif for steps to reproduce the problem.
(In reply to Dani Megert from comment #86) > I haven't looked at any detail yet, but want to mention that 'Unapply' is a > bad/misleading name. We already have 'Revert'. Maybe use more specific names > to link and unlink. Dani, I take into account your remark. Thank you
(In reply to Sarika Sinha from comment #89) > Created attachment 269092 [details] > Steps for highlightling issue > > Attaching the gif for steps to reproduce the problem. Sarika, I reproduce the problem on Windows. So it is a platform related problem. I will take a look as soon as possible. Thank you, and feel free to test the others aspects of the feature. Best regards, Axel
I commented https://bugs.eclipse.org/bugs/show_bug.cgi?id=508103 which describes succinctly the windows related problem. I hope it will not block you Sarika to test the rest of the feature
(In reply to Axel RICHARD from comment #92) > I commented https://bugs.eclipse.org/bugs/show_bug.cgi?id=508103 which > describes succinctly the windows related problem. > > I hope it will not block you Sarika to test the rest of the feature Will check with SWT team, if there is a problem with support from Windows platform itself. If it can not be resolved, we can look into a different way of identifying the difference , like marking with "*" etc. I will be looking into other portions in detail as well. Let's target for M2.
We have a SWT patch in process for the Windows bug. Hoping to work it through in M3.
(In reply to Sarika Sinha from comment #93) > I will be looking into other portions in detail as well. Let's target for M2. Hello Sarika, M2 is over now and I see no review for my work. Do you plan to review it in the next days ? Or do you wait M3 to review it (combined with the SWT patch) ? Best regards, Axel
Yes, I will be reviewing it next week.
(In reply to Sarika Sinha from comment #96) > Yes, I will be reviewing it next week. Ok great, thank you !
https://git.eclipse.org/r/#/c/93749/ Not able to rebase it due to merge conflicts, Can you please do it?
We will also need svg files for all the new images.
New Gerrit change created: https://git.eclipse.org/r/106473
(In reply to Sarika Sinha from comment #98) > https://git.eclipse.org/r/#/c/93749/ > Not able to rebase it due to merge conflicts, Can you please do it? Done
(In reply to Axel RICHARD from comment #101) > (In reply to Sarika Sinha from comment #98) > > https://git.eclipse.org/r/#/c/93749/ > > Not able to rebase it due to merge conflicts, Can you please do it? > > Done Thanks!! seeing an unexpected behavior after changing Launch Configuration name which is linked to prototype and pressing Apply. The dialog shows "Java Application" UI for a second and then comes back to the selected Java Run Configuration. Attaching gif to show how it looks.
Created attachment 270894 [details] Gif to Show Apply after Launch Config name change
What is the expected behavior on Export/Import of a launch Configuration which is linked to a prototype ? Currently, What I see is if I export a Configuration which is linked to Prototype and import in another workspace, it is not visible in the Launch Configuration Dialog till the linked prototype is also imported ? I think there should be an option to export/import a Prototype with the children and a Launch Configuration with the linked Prototype as well.
I am trying with I20171010-2000 which should have Bug 516365 resolved. And the patches https://git.eclipse.org/r/#/c/92991/ and https://git.eclipse.org/r/#/c/93749/ from Bug 41353, But I still don't see highlighted item which has changes.
Moving to M4.
(In reply to Sarika Sinha from comment #99) > We will also need svg files for all the new images. Where do I need to put the svg files for all new images ?
(In reply to Sarika Sinha from comment #102) > Thanks!! seeing an unexpected behavior after changing Launch Configuration > name which is linked to prototype and pressing Apply. The dialog shows > "Java Application" UI for a second and then comes back to the selected Java > Run Configuration. > Attaching gif to show how it looks. Ok I will fix it soon.
(In reply to Axel RICHARD from comment #107) > (In reply to Sarika Sinha from comment #99) > > We will also need svg files for all the new images. > > Where do I need to put the svg files for all new images ? It should go to org.eclipse.images plugin in eclipse.platform.images repository.
New Gerrit change created: https://git.eclipse.org/r/110556
(In reply to Sarika Sinha from comment #99) > We will also need svg files for all the new images. https://git.eclipse.org/r/#/c/110556/
(In reply to Sarika Sinha from comment #102) > Thanks!! seeing an unexpected behavior after changing Launch Configuration > name which is linked to prototype and pressing Apply. The dialog shows > "Java Application" UI for a second and then comes back to the selected Java > Run Configuration. > Attaching gif to show how it looks. Fixed with the latest version of https://git.eclipse.org/r/#/c/92991/
(In reply to Sarika Sinha from comment #104) > What is the expected behavior on Export/Import of a launch Configuration > which is linked to a prototype ? Currently, the import and export don't handle links between prototype and classic launch configurations. > I think there should be an option to export/import a Prototype with the > children and a Launch Configuration with the linked Prototype as well. It was not part of the related FEEP (https://projects.eclipse.org/development_effort/launch-configuration-templates) but I can add the mechanism -for the export dialog: -- via right-click options (select all children on a prototype, and select linked prototype on a launch configuration) -- via the existing checkboxes, but in this case, a prototype won't be selectable alone (its children will be automatically selected along with) -for the import dialog it is more difficult, because the items are org.eclipse.debug.internal.ui.importexport.launchconfigurations.ImportLaunchConfigurationsWizardPage.DebugFileSystemElement and not org.eclipse.debug.core.ILaunchConfiguration elements. So I think it should be done in a future iteration. What do you think about ?
(In reply to Axel RICHARD from comment #113) > What do you think about ? Allowing only for export does not make sense, Please create a new bug to handle import and export for Prototypes. Adding Vikas to look into PDE impact. I will look into the latest changes.
Removing "depends on Bug 516365", as that was only for dark theme. Native Windows does not allow highlighting of rows for disabled tables. So we need to find other options which work on all platforms - 1. Select the rows which have changes values 2. Another column which has an indicator to show the values have changed Any other suggestion ? The Flickering problem is resolved now.
(In reply to Sarika Sinha from comment #114) > (In reply to Axel RICHARD from comment #113) > > > What do you think about ? > > Allowing only for export does not make sense, Please create a new bug to > handle import and export for Prototypes. > Adding Vikas to look into PDE impact. > > I will look into the latest changes. Thank you Sarika. I just created the ticket for import/export https://bugs.eclipse.org/bugs/show_bug.cgi?id=527239
(In reply to Sarika Sinha from comment #115) > Removing "depends on Bug 516365", as that was only for dark theme. Native > Windows does not allow highlighting of rows for disabled tables. So we need > to find other options which work on all platforms - > 1. Select the rows which have changes values > 2. Another column which has an indicator to show the values have changed > > Any other suggestion ? > > The Flickering problem is resolved now. Any suggestion here? Otherwise most of the things look ok now.
Hi Sarika, Do I need to put some doc somewhere ? Best regards,
(In reply to Axel RICHARD from comment #118) > Hi Sarika, > > Do I need to put some doc somewhere ? > > Best regards, Hi Axel, Nothing in any doc, just looking for some suggestion to solve the Windows highlighting of rows for disabled tables. Without that it will be difficult to release.
(In reply to Sarika Sinha from comment #119) > Hi Axel, > Nothing in any doc, just looking for some suggestion to solve the Windows > highlighting of rows for disabled tables. Without that it will be difficult > to release. Hi Sarika, Thank you for the answer. Ok, I will try to look at this problem, but no guarantee to solve it as I'm not familiar with swt platform code. Best regards,
(In reply to Axel RICHARD from comment #120) > (In reply to Sarika Sinha from comment #119) > > Hi Axel, > > Nothing in any doc, just looking for some suggestion to solve the Windows > > highlighting of rows for disabled tables. Without that it will be difficult > > to release. > > Hi Sarika, > > Thank you for the answer. Ok, I will try to look at this problem, but no > guarantee to solve it as I'm not familiar with swt platform code. > > Best regards, Sorry I misunderstood your last comment. Ok I will look at your suggestions (https://bugs.eclipse.org/bugs/show_bug.cgi?id=41353#c117) and try to see If there are also others possibilities. Best regards,
Sarika, I just pushed a new version of the contribution. It try to replace the highlighted rows by selected rows but it doesn't work on windows, only on mac like the highlighted rows. The disabled state of swt trees are definitely much better handled on mac. So I used the checkoboxes of the swt tree. Indeed, the checkboxes have three states: checked, unchecked and grayed. I used the grayed state to indicate a modified attribute (with a value different from its prototype). It works well on both windows and mac platforms. Hope it will suits you. Best regards,
(In reply to Axel RICHARD from comment #122) > Sarika, > > I just pushed a new version of the contribution. > > It try to replace the highlighted rows by selected rows but it doesn't work > on windows, only on mac like the highlighted rows. The disabled state of swt > trees are definitely much better handled on mac. > > So I used the checkoboxes of the swt tree. Indeed, the checkboxes have three > states: checked, unchecked and grayed. I used the grayed state to indicate a > modified attribute (with a value different from its prototype). It works > well on both windows and mac platforms. > > Hope it will suits you. > > Best regards, Thanks Alex for making the changes. I tried out the latest change. Now we can see the changes on Windows as well, after looking at the tab I felt only issue that seeing the checkbox user can get confused that user can do some action. Other thought can be do provide two Icons to differentiate instead of check box in the same column. Let me know your thoughts.
Sarika, Thank you for the review. I just pushed a new version of the contribution (https://git.eclipse.org/r/#/c/92991/18). In this version, a new column is displayed ("Modified"). If an attribute has been modified in a launch configuration (and then is different from its prototype), then "true" is displayed in the cell, otherwise "false" is displayed. I don't use checkboxes because it seems not possible tu use checkboxes in another column than the first column (it seems possible to display a "checked" image and an "unchecked" image, but I think this is not a proper way to do the trick, because checkboxes images are platform dependent). Is it suitable for you ? Best regards,
Yes, now it looks ok. You can fix some missing @since as commented gerit. And, should we put all the attributes which have value to be be applied by default? I think we should let the users select the attributes, what do you say ? As currently users will have to go and remove as many of them does not make sense to be propagated.
(In reply to Sarika Sinha from comment #125) > Yes, now it looks ok. > You can fix some missing @since as commented gerit. > > And, should we put all the attributes which have value to be be applied by > default? I think we should let the users select the attributes, what do you > say ? > > As currently users will have to go and remove as many of them does not make > sense to be propagated. We need to complete it this week to be able to deliver for M4.
(In reply to Sarika Sinha from comment #126) > We need to complete it this week to be able to deliver for M4. I took into account all the comments in the contributions.
(In reply to Sarika Sinha from comment #125) > Yes, now it looks ok. > You can fix some missing @since as commented gerit. > > And, should we put all the attributes which have value to be be applied by > default? I think we should let the users select the attributes, what do you > say ? > > As currently users will have to go and remove as many of them does not make > sense to be propagated. It is a good question. Both approaches are possible here: all attributes selected by default or none. I think, in the most common cases, users will want to have all attributes selected by default and just unselect some of them. But this is just a feeling.
Thinking again, I think it is ok to keep them checked. We can see if users want it the other way. Only 1 thing pending now - currently we are allowing to add Prototypes in the launch group which does not make sense and doesn't work. We need to filter them from the list while adding launches to a Launch Group.
I have moved to M5, planning to release early M5, week of 11th Dec so that we can ask users to test it with all types of launch configurations after it gets into the I build and other components will have time to react to the change.
(In reply to Sarika Sinha from comment #129) > Thinking again, I think it is ok to keep them checked. > We can see if users want it the other way. > > Only 1 thing pending now - currently we are allowing to add Prototypes in > the launch group which does not make sense and doesn't work. We need to > filter them from the list while adding launches to a Launch Group. I only forbid the selection of prototypes in the Launch Group Dialog (and added an error message when a prototype is selected). I think this is the best approach, because it keeps intact the tree of launch configurations, and allows to see which configuration is associated to a prototype in this Launch Group Dialog.
Gerrit change https://git.eclipse.org/r/92991 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=ca4c3de585c743486c2df55b551ec3f2dfd9b6a2
Gerrit change https://git.eclipse.org/r/110556 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.images.git/commit/?id=d7d82722610a4b292aa37d0b57a380ea0436d453
Have release Platform Debug and Images. Will release JDT changes tomorrow after the gerrit validates changes with tomorrow build. @Vikas, You can also review and release after tomorrow's build.
Have released JDT changes. @Axel , please look into Bug 528469.
Gerrit change https://git.eclipse.org/r/93749 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=96d0d574c36f9c96740b1006d02efdaea625036e
New Gerrit change created: https://git.eclipse.org/r/113203
Gerrit change https://git.eclipse.org/r/113203 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=3d597d584f2f8447ee22514b4cc6c165cac7d401
Prototype creations for Java Application is available in Eclipse SDK Version: Photon (4.8) Build id: I20171212-2000 @Axel, we will need a N&N (New & Noteworthy) entry using the news repository: www.eclipse.org/eclipse/news.git
Gerrit change https://git.eclipse.org/r/93140 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=63a8e91cb2d09ad3e770434aaf883100ee312cce
I tested this for PDE launcher changes. It works well ( Thanks Sarika for helping out). The code looks good and I have released the changes. I will verify in the next build and test some more once it gets in the build. We need a N&N entry in PDE as well.
New Gerrit change created: https://git.eclipse.org/r/113521
Gerrit change https://git.eclipse.org/r/113521 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=9edc5d892d396f34182031d9f8718ae96cf1a0c9
New Gerrit change created: https://git.eclipse.org/r/113607
Gerrit change https://git.eclipse.org/r/113607 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=a3450fbfe0931f19f854c01f65674a3793353a9c
(In reply to Eclipse Genie from comment #145) > Gerrit change https://git.eclipse.org/r/113607 was merged to [master]. > Commit: > http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=a3450fbfe0931f19f854c01f65674a3793353a9c > This reverted the previous change. See Gerrit for details.
Resolving the bug now. Thanks Axel.
New Gerrit change created: https://git.eclipse.org/r/114379
(In reply to Sarika Sinha from comment #147) > Resolving the bug now. > Thanks Axel. Thank you very much Sarika for all your reviews. I just pushed a contribution for the N&N : https://git.eclipse.org/r/114379 Best regards,
Gerrit change https://git.eclipse.org/r/114379 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=64145fe33088c923da38124e67be91d92f261a3f
New Gerrit change created: https://git.eclipse.org/r/115747
Gerrit change https://git.eclipse.org/r/115747 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=1b6d41c9b7bf9e08a9a9db26d5e51cc175ad4d31
Verified using Eclipse SDK Version: Photon (4.8) Build id: I20180121-2000
New Gerrit change created: https://git.eclipse.org/r/118401
Gerrit change https://git.eclipse.org/r/118401 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.images.git/commit/?id=e28245e724aa560dd38bd1e103b1086b61eea637
New Gerrit change created: https://git.eclipse.org/r/122184
Reopening to make sure the latest Gerrit change gets included.
Gerrit change https://git.eclipse.org/r/122184 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=619f6a83779c6806bfd48a8abf9250cfe9b88d3c
Marking as FIXED now that the documentation has been added.
We don't have Prototype tab for Remote Java Application.
