Community
Participate
Working Groups
Shared launch configuration depends on the project name. This is inconvenient because if I check out a project as something other than the module/dir name, my shared launch configurations won't work without modification. The launch configuration needs to have some kind of project variable that can be determined based on the project's actual name rather than "hard-coding" the project name into the launch configuration. I think this should be clear, but if it is not, please let me know and I'll add more details.
*** Bug 61488 has been marked as a duplicate of this bug. ***
*** Bug 61487 has been marked as a duplicate of this bug. ***
There's really two issues here: (1) The launch config itself stores the project name in the launch config handle. We could fix this relatively easily, to be dynamic based on its project (actually, not include the project) (2) References to the launch config can become stale. For example, the lanuch history contains mementos to launch config handles (which point to the location of the config, containing the project name). If you change the project name, the handles now point to the wrong things. Fixing up incorrect references is not a simple task (i.e. we can't do it), and this is the real usability problem, I believe. Can you expand on how the problem manifiests itself? I.e. what do you see broken first when you do this?
There seems to be some confusion (maybe just with me) about what a shared launch configuration is. It seems to me that there needs to be better separation between available persisted launch configurations (shared) and launch history (local). As a case in point, if I want to delete all my local historical launches, I have to carefully examine each of them to ensure that I don't delete a shared launch configuration. This is very inconvenient--and probably needs to be another, different, issue. When I mark a launch configuration as shared, I want it to be available to anyone who checks out the project (regardless of the name by which the project is checked out). So to answer your question, I believe the primary problem fits your first description. If I check out a project for the first time using a non-default project name, the shared configurations show up in my favorites, but they don't work because the configuration file itself references the default project name. As an aside (probably related to my previous tangent), note that I always tend to mark shared configurations as favorites--it seems that I have to do this if I want other to be able to easily run these shared configurations (i.e., without having to sift through every previous launch I've ever done to find it). Am I missing something? Is there an easy way to launch a non-favorite shared configuration, if I've never launched it before (like right-clicking on the configuration file and selecting "launch")? This seems to be related to the non-distinction between launch history and available launches.
When a user imports a new "shared" launch config, it will appear in their launch dialog, but only appears in favorites if it is marked as a favorite. Currently, we do not support contenxt launching (i.e. context menu) for launch configs in the workspace. Deferred for post 3.0 consideration.
I realize that I've probably brought up a couple of related, but distinct issues/enhancements. However, I would ask you to reconsider including a fix for the first issue you described in comment 3 (especially since you say it would be relatively easy). That is the problem that I'm actually reporting here (sorry to have muddied the water a bit), and fixing it *would* make shared launch configurations significantly more useful. Please see the second paragraph in my comment 4. Thanks!
Actually, when I import a shared launch config into a different project - it works for me. And looking at the code, it looks like it should. What error do you get? Is there a stack trace?
Created attachment 10651 [details] Relevant excerpt from my log
Sorry, I should've included all of this information from the beginning. FYI, I'm running build 200403261517 (3.0M8). I attached an excerpt of the relevant portion of my log file. Finally, here's a detailed description of what I'm doing to create this: 1. Create a shared launch configuration called "launch" in project "project-x". 2. Mark it as a favorite. 3. Check the changes into CVS. (The CVS module/directory is "project-x".) 4. Delete project "project-x" (including the resources). I think the shared launch "launch" disappears from my favorites at this point (as I would expect). 5. Check out the "project-x" module/directory from CVS as "project-y". At this point "launch" reappears in my favorites. 6. Select "launch" from my favorites, and this error occurs. Hope this helps. Thanks!
I don't think the log is the correct portion - it is dispaying refactoring errors, and there is no mention of the debug "launch" action. There should likely be a "LaunchAction" in the stack trace if you invoke a favorite.
Ok, you're right (sort of :). I just deleted my log file and recreated the error. What follows is my entire log file: !ENTRY org.eclipse.jdt.launching 4 107 May 14, 2004 11:35:31.802 !MESSAGE Launch configuration Realm Commons Tests references non-existing project realmCommons. In this log, "Realm Commons Tests" corresponds to my hypothetical shared favorite launch configuration, "launch". "realmCommons" corresponds to my hypothetical project, "project-x".
OK - do not intend to fix this for 3.0. The problem did not occurr for me, since I just exported the launch config from project A, that launched something in project B. I then imported the config into project C, and thus the launch works, since project B still existed. However, this is a different problem than I was anticiapting (I verified that the config itself could be read and was valid). This problem is that the project attribute is now invalid, and there is no limitation on what project a config references (i.e. class to run) vs what project it resides in.
please look at it as soon as possible (then after 3.0 if really needed) because shared configuration should really be project independend, It should look at the project it is currently in and use that one as its base project.. The basic example when the shared configuration is always going wrong is when you check out a branch of the project. Most of the time if you checkout a branch the project name will be somthing like: "project_20" instead of just "project". Branch projects have to have another name because the "project" project is also in the workspace because that contains my work on HEAD.
Needs more investigation.
Deferred
I suggest the following solution to the problem (for release 3.2m6): package org.eclipse.jdt.launching; public abstract class AbstractJavaLaunchConfigurationDelegate { public IJavaProject getJavaProject(ILaunchConfiguration configuration) { String projectName = getJavaProjectName(configuration); if (projectName != null) { projectName = projectName.trim(); if (projectName.length() == 0) { >>get the project name from the shared location the launch configuration: projectName = configuration.getSharedLocationRoot; << } if (projectName.length() > 0) { IProject project = ResourcesPlugin.getWorkspace().getRoot() .getProject(projectName); IJavaProject javaProject = JavaCore.create(project); if (javaProject != null && javaProject.exists()) { return javaProject; } } } return null; } } This would leave the project name unaltered (empty string), but solve the places where the IProject reference is needed, without changing too much.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
