Community
Participate
Working Groups
From Darin W: the debug platform is performing the build as controlled by the preference. The debug platform is not aware of what project is being launched - a notion that is specific to a type of launch configuration, which is contributed by other plug-ins. E.g. the JUnit launch config knows that it may pertain to a project, but the debug platform has no way of finding this out. Thus, an incremental build is performed on the workspace. ... the debug plug-in is not aware of what project is being launched. The required information is not currently available - it would require the co-operation of all existing launch configuration types to tell the debug plug-in what project is being launched - an API which does not exist." This bugzilla is for asking for this new API/enhancement, to ensure the build is kicked off on the project which is being selected for launch, not on the whole workspace.
Marking as 3.0 candidate. Requires a way to optionally map a launch config to a project. The same support could be leveraged to support bug 19521.
*** Bug 45891 has been marked as a duplicate of this bug. ***
*** Bug 49160 has been marked as a duplicate of this bug. ***
*** Bug 52068 has been marked as a duplicate of this bug. ***
Adding Jim as CC, since Jim is also investigating scoped builds.
Though I agree that bug 52068, which was marked as a duplicate of this one, is probably related, please also take into account my original comments there, which were about plug-ins I had rendered invisible in the launch configuration.
Note that any solution to this problem will likey require domain specific knowledge from a launch configuration type (i.e. to get the proper "config -> project" dependency information)
Comment #7 is true of this bug, but not of bug 52068 that was marked as a duplicate. In that case, projects were being *re*built that were fully built. Preventing this should require only information local to the projects.
In 3.0, the debug platform has introduced ILaunchConfigurationDelegate2 which provides optional hooks for launch delegates to implement. The hooks allow for * providing a launch object to seed a launch (or re-use an existing launch) * allow for initial sanity pre-launch checks/abort (bug 6400) * pre-lanuch build * final final pre-launch checks/abort (for bug 54925) It will be up to launch delegates to implement the building required by their launch configration.
Will provide an implementation for Java launch configs (local Java apps, Applets, JUnit, Remove Java Apps) that builds referenced projects.
Created attachment 8657 [details] patch to debug.core
Created attachment 8658 [details] patch to jdt.debug.ui
Created attachment 8659 [details] patch to jdt.launching
patches address this bug as well as Bug #6400 and Bug #54925
Darin, please verify
We now have a Java specific solution that ties into the ILaunchDelegate2 support (pre launch checks & build). We should look at ways to generalize this support in the debug platform.
Added convenience methods to LaunchConfigurationDelegate protected IProject[] getBuildOrder(IProject[] projects) protected void fillReferencedProjectSet(IProject project, HashSet referencedProjSet) protected IProject[] orderProjectSet(IProject[] projectSet) protected boolean existsProblems(IProject proj, int severity) Made changes to AbstractJavaLaunchConfigurationDelegate to take advantage of the new convenience methods.
Darin, please verify changes in LaunchConfigurationDelegate and AbstractJavaLaunchConfigurationDelegate
Verified. I renamed a few methods in the abstract superclass, and added logic to the top-level "buildForLaunch(...)" method. Subclasses just have to override "getBuildOrder(...)" which returns a set of projects to build.
*** Bug 59311 has been marked as a duplicate of this bug. ***
*** Bug 15343 has been marked as a duplicate of this bug. ***
*** Bug 39832 has been marked as a duplicate of this bug. ***
