Community
Participate
Working Groups
Currently, the CDI launch delegates are named using the word "Sandard", e.g., "Standard Create Process Launcher". It think that since DSF has been the default launcher for over 3 years now, it would be clearer to rename the launch delegates to reflect this reality.
Should we eliminate these from the UI altogether yet? CDI's been deprecated for a long time now.
(In reply to Doug Schaefer from comment #1) > Should we eliminate these from the UI altogether yet? CDI's been deprecated > for a long time now. CDI sometimes gives us a workaround when there is an issue with DSF with some special targets. Also, I believes it supports older GDB versions. Those CDI delegates are not easily seen in the UI, so removing them may not be essential. I personally feel safer keeping them (discretely as they are now).
I think it's a good idea to rename the CDI delegate so that it doesn't have "Standard" in it. It is a bit confusing at first. Removing CDI from the UI could be a separate discussion. One approach could be to move it out of the main features to an optional feature that way most users will not have to see it anymore. I still find it useful to compare how they behave.
+1 to move to optional features. This most probably would mean to split in separate plugin CDI launch delegates from org.eclipse.cdt.launch and org.eclipse.cdt.launch.remote There're some additional UI that will be less cluttered for nowadays *standard* DSF launchers. On other note to remove the legacy CDI launcher we should mark "deprecated" public CDI interfaces so that in a 9.0 release to be able to remove it. e.g. org.eclipse.cdt.debug.core.ICDIDebugger2
(In reply to Teodor Madan from comment #4) > +1 to move to optional features. > > This most probably would mean to split in separate plugin CDI launch > delegates from org.eclipse.cdt.launch and org.eclipse.cdt.launch.remote > > There're some additional UI that will be less cluttered for nowadays > *standard* DSF launchers. > > On other note to remove the legacy CDI launcher we should mark "deprecated" > public CDI interfaces so that in a 9.0 release to be able to remove it. > e.g. org.eclipse.cdt.debug.core.ICDIDebugger2 Are you suggesting to remove the code? We have customers that use the CDI debugger with our toolchain. What are they supposed to do?
I pushed to gerrit a first patch which only changes the word 'standard' to 'legacy': https://git.eclipse.org/r/21106 So it would be, for example: "Legacy Create Process" "Start new application optionally under control of the legacy debugger." Unless someone does not like that wording, I suggest we commit this patch for the 8.3 release and master. Splitting into optional features would be done separately and not for 8.3.
I've pushed the same patch for 8_3 to gerrit: https://git.eclipse.org/r/21109
(In reply to Mikhail Khodjaiants from comment #5) > Are you suggesting to remove the code? We have customers that use the CDI > debugger with our toolchain. What are they supposed to do? Not really, at least not in near future. The first step, regardless if we would remove the API ever would be to mark API deprecated, as a sign that in few years span it might be not very well supported. As the process of removal, initial step might be to deploy the CDI code as a separate fragment bundle in order not to affect bundle dependencies of CDI debuggers.
(In reply to Marc Khouzam from comment #6) > So it would be, for example: > "Legacy Create Process" > "Start new application optionally under control of the legacy debugger." I wonder if it would be better to call it CDI Create Process. Because some users that do need to use CDI might think they need to change to DSF because "Legacy" sounds worst. That way DSF-GDB and CDI would be on equal ground except that DSF-GDB is the default selected one (in open source at least). But it's really up to people using CDI in their product, as long as it's not called "Standard" anymore then I'm happy. > Splitting into optional features would be done separately and not for 8.3. Sounds good!
(In reply to Marc-Andre Laperle from comment #9) > (In reply to Marc Khouzam from comment #6) > > So it would be, for example: > > "Legacy Create Process" > > "Start new application optionally under control of the legacy debugger." > > I wonder if it would be better to call it CDI Create Process. Because some > users that do need to use CDI might think they need to change to DSF because > "Legacy" sounds worst. That way DSF-GDB and CDI would be on equal ground > except that DSF-GDB is the default selected one (in open source at least). > But it's really up to people using CDI in their product, as long as it's not > called "Standard" anymore then I'm happy. Mikhail, what do you think? Is it better for your users to see "CDI Create Process" or is "Legacy Create Process" ok? I used 'Legacy' instead of 'CDI' because I wanted to guide users towards the default debugger and I thought 'Legacy' would do that, but I'm not attached to the wording.
(In reply to Marc Khouzam from comment #10) > Mikhail, what do you think? Is it better for your users to see "CDI Create > Process" or is "Legacy Create Process" ok? I used 'Legacy' instead of 'CDI' > because I wanted to guide users towards the default debugger and I thought > 'Legacy' would do that, but I'm not attached to the wording. Marc, it doesn't matter for our customers, they use their own launch configuration types. But any changes in the API would break their code. That's why I am not very enthusiastic about some of these proposals.
(In reply to Mikhail Khodjaiants from comment #11) > (In reply to Marc Khouzam from comment #10) > > Mikhail, what do you think? Is it better for your users to see "CDI Create > > Process" or is "Legacy Create Process" ok? I used 'Legacy' instead of 'CDI' > > because I wanted to guide users towards the default debugger and I thought > > 'Legacy' would do that, but I'm not attached to the wording. > > Marc, it doesn't matter for our customers, they use their own launch > configuration types. But any changes in the API would break their code. > That's why I am not very enthusiastic about some of these proposals. API changes aren't allowed. Of course, you already know that ;).
(In reply to Mikhail Khodjaiants from comment #11) > Marc, it doesn't matter for our customers, they use their own launch > configuration types. But any changes in the API would break their code. > That's why I am not very enthusiastic about some of these proposals. No API changes. I'll commit the name change for 8.3 and master. After that, I believe a refactoring will simply move some use of extensions to a new plugin but the code will stay in the same place. To be honest, splitting up the code (even if we could change the API) would require a bigger effort than what I'm willing to put :) I'll post something a little later that would make the 'Legacy' launches an optional feature, while leaving everything else as is.
(In reply to Marc Khouzam from comment #13) > I'll commit the name change for 8.3 and master. Done
(In reply to Marc Khouzam from comment #13) > After that, I believe a refactoring will simply move some use of extensions > to a new plugin but the code will stay in the same place. To be honest, > splitting up the code (even if we could change the API) would require a > bigger effort than what I'm willing to put :) We all know that all these talks about splitting up the code are unrealistic. Let's focus on something more important.
(In reply to Marc Khouzam from comment #14) > (In reply to Marc Khouzam from comment #13) > > > I'll commit the name change for 8.3 and master. > > Done Marc, can this bug be marked as RESOLVED then?
(In reply to Marc-Andre Laperle from comment #16) > Marc, can this bug be marked as RESOLVED then? There was a suggestion to refactor the code so that the CDI launch delegates be into an optional feature. I have a patch that is almost ready but had no time to complete it yet.
(In reply to Marc Khouzam from comment #17) > (In reply to Marc-Andre Laperle from comment #16) > > > Marc, can this bug be marked as RESOLVED then? > > There was a suggestion to refactor the code so that the CDI launch delegates > be into an optional feature. I have a patch that is almost ready but had no > time to complete it yet. Ah, I thought this would be addressed in a separate bug. What do you think? Renaming the launch delegate and moving CDI into an optional feature are two separate things in my mind. One is done in 8.3 and one will be in Luna (8.4?).
(In reply to Marc-Andre Laperle from comment #18) > (In reply to Marc Khouzam from comment #17) > > (In reply to Marc-Andre Laperle from comment #16) > > > > > Marc, can this bug be marked as RESOLVED then? > > > > There was a suggestion to refactor the code so that the CDI launch delegates > > be into an optional feature. I have a patch that is almost ready but had no > > time to complete it yet. > > Ah, I thought this would be addressed in a separate bug. What do you think? > Renaming the launch delegate and moving CDI into an optional feature are two > separate things in my mind. One is done in 8.3 and one will be in Luna > (8.4?). You are right that it would be clearer that way. Do you mind opening the new bug?
(In reply to Marc Khouzam from comment #19) > Do you mind opening the new bug? Bug 427382.
Fixed.
