Community
Participate
Working Groups
I discovered accidentally that you can embed .launch files with individual projects, and if you do, clicking right on them presents the "debug as" and "run as" actions. This is a great start, but if you use these launches, the global list of launches becomes confused and confusing. The per-project launches seem to appear twice in the global launch list. Also, opening the .launches associated with the project defaults to opening with an XML editor, and there seems to be no way to choose the usual .launch editor. (you can edit them by choosing one of the duplicated entries out of the global launch list). Please make these per-project launches into first class citizens.
You can see a related enhancement which is being worked upon : Bug 461889.
This continues to be really annoying. I keep .launch files in the source hierarchy, so they are associated with the sources and source control. However, all of these launches appear twice in the list of launches. I investigated a little more, and found that one copy is from the original source folder, the other is from the bin folder where the class files end up. Worse, the bin copy is editable, but the edited copy will be trashed by the next clean build.
(In reply to Dave Dyer from comment #2) > I investigated a little more, and found that one copy is from > the original source folder, the other is from the bin folder > where the class files end up. You should exclude .launch files to be copied in the project build settings: Java compiler -> building -> Output folder -> Filtered resources
that can paper over the problem, but why are .launches in the /bin directory considered at all? There's no sensible way they can be used there.
(In reply to Dave Dyer from comment #4) > that can paper over the problem, Right, this was a quick fix proposal for you. > but why are .launches in > the /bin directory considered at all? There's no sensible > way they can be used there. Therefore I would change this bug title to "Ignore launches from derived folders". Please if you have other requests, create additional tickets.
New Gerrit change created: https://git.eclipse.org/r/94128
(In reply to Andrey Loskutov from comment #5) > (In reply to Dave Dyer from comment #4) > > but why are .launches in > > the /bin directory considered at all? There's no sensible > > way they can be used there. > > Therefore I would change this bug title to "Ignore launches from derived > folders". > New Gerrit change created: https://git.eclipse.org/r/94128 @Sarika: WDYT?
(In reply to Andrey Loskutov from comment #7) > (In reply to Andrey Loskutov from comment #5) > > (In reply to Dave Dyer from comment #4) > > > but why are .launches in > > > the /bin directory considered at all? There's no sensible > > > way they can be used there. > > > > Therefore I would change this bug title to "Ignore launches from derived > > folders". > > > New Gerrit change created: https://git.eclipse.org/r/94128 > > @Sarika: WDYT? Code changes look logical, but first please help me in reproducing the problem. I saved a launch in src/temp folder. I don't have any filter for Output folder but I don't see any launch file in bin directory ?
my launches are in the same folder as the .java
(In reply to Sarika Sinha from comment #8) > (In reply to Andrey Loskutov from comment #7) > > (In reply to Andrey Loskutov from comment #5) > > > (In reply to Dave Dyer from comment #4) > > > > but why are .launches in > > > > the /bin directory considered at all? There's no sensible > > > > way they can be used there. > > > > > > Therefore I would change this bug title to "Ignore launches from derived > > > folders". > > > > > New Gerrit change created: https://git.eclipse.org/r/94128 > > > > @Sarika: WDYT? > > Code changes look logical, but first please help me in reproducing the > problem. > I saved a launch in src/temp folder. I don't have any filter for Output > folder but I don't see any launch file in bin directory ? You probably have excludes .launch files to be copied in the project (or workspace) build settings: Java compiler -> building -> Output folder -> Filtered resources The only concern I have for the proposed patch: are there cases where the launch files are *generated and marked as derived*? If so, this could break someone who generates launches programmatically. If so, should we make an option "Run/Debug-> Launching -> Lanch Configuration -> Filter configurations from derived folders"?
(In reply to Andrey Loskutov from comment #10) > You probably have excludes .launch files to be copied in the project (or > workspace) build settings: Java compiler -> building -> Output folder -> > Filtered resources i don't have this filter. I also have the .launch file along with .java file in a package under src. Preference, we can add, but how to make it easily discover able? People will about this feature.
(In reply to Sarika Sinha from comment #11) > (In reply to Andrey Loskutov from comment #10) > > > You probably have excludes .launch files to be copied in the project (or > > workspace) build settings: Java compiler -> building -> Output folder -> > > Filtered resources > i don't have this filter. I've seen that I hat to trigger a "full build" after creating a launch so that the copy of that was copied to the bin directory. > I also have the .launch file along with .java file in a package under src. > > Preference, we can add, but how to make it easily discover able? People will > about this feature. I'm not sure if and how often people create "derived" launches. In our lab we don't do that and I haven't seen this yet. However I've saw many times people trying to understand how to avoid launch "duplication" because they changed they default build settings. So most likely most people would not notice anything, and those who will, will need to check the prefs or ask in forum.
Andrey, are you planning to fix this for 4.7?
(In reply to Noopur Gupta from comment #13) > Andrey, are you planning to fix this for 4.7? No, see comment 10. The patch should include a new preference to disable the new behavior, because I fear we could break some use cases where the launch files are derived *per purpose* because they could be generated by some clever tooling.
The patch requires preference check, but I have no interest to spent time for this. May be someone can pick up and polish it.
