Feeling rather dumb: I have a C++ project, using Eclipse CDT (Eclipse 3.6, CDT 1.3.1).
I have defined more than one launch configuration: each points to a different executable within the project. But, when I press F11 to debug, Eclipse always loads the first configuration, and I can find no way to make it launch the 2nd one instead.
Surely this deserves a menu or dialog setting somewhere?
For each of your projects:
Project > Properties > C/C++ Build > Manage Configurations... > Set Active
Related
I'm trying to use EclEmma with Eclipse, but I can't get it to work. I can't see the button that's supposed to launch my project in Coverage mode, There;s also no such option in Run menu:
I've tried to fix it in two ways I've found on the Internet, and none worked:
the EclEmma help page says that I should enable the Coverage command group on the Commands tab in the Customize Perspective dialog, but there's no such tab in the dialog and no Coverage command group in existing tabs
I tried to find “Java Code Coverage” in Window > Preferences > General > Appearance > Label Decorators menu - not there
I'm using Eclipse Mars.2 Release (4.5.2) on Windows 10, I have EclEmma v. 2.3.3.201602231923 (according to Help > About Eclipse > Installation Details) installed via Eclipse Marketplace. I have no idea how to fix it, I'll appreciate any help.
In eclipse 4.9 (2018-9) the option to enable the "Coverage as ..." command can be found in "Customizing Perspective" (rightclick on the perspective shortcut), then on tab page "Action Set Availability": Click the "Java Code Coverage" option.
Another problem I encountered: Although the "Coverage as..." command was available, there was no result visible at the end in the view "Coverage". The problem can be solved by following the advice from the eclEmma FAQ:
The Coverage view stays empty and there is no source highlighting. Why?
In Eclipse preferences there is an option Launch in debug mode when workspace contains breakpoints under Run/Debug → Launching. If this option is enabled and there are breakpoints in your workspace coverage mode will not work, because it is automatically replaced with debug mode. Set this option to Never if you want to run code coverage analysis.
BTW: I am using eclEmma plugin 3.1.2
Migrating from Worklight Studio 5.0.6 to 6.0
We observe a small, but undesirable, difference in behaviour, or maybe a confiuguration chenge is needed somewhere we failed to find.
In v5.0.6 when one selects an environment and requests Build Environment and Deploy, the project's Builders are first executed. In v6.0 this does not appear to be the case, unless there's a option somewhere ...
The use case is that we have some pre-processing carried out by an ant task installed as a project builder. In v6.0 we now need to rememeber to run a Build Project and then build the environment.
Is there an option to control this behaviour?
this is how to run ant task in worklight 5.0.x - 6.x:
create the Ant file (build.xml):
Navigate to project->properties->Builders->new->Ant Builder. press ok
in "Main" tab set the name for the builder and choose your Ant file (build.xml):
in "Targets" tab choose when to run the Ant file (in this exemple in Auto Build):
press OK
press OK
run "Build All and Deploy":
Success:
This is an open defect in Worklight 6.0.0.x and 6.1.0.x.
There is currently no workaround for it.
My eclipse is constantly running "Build Workspace" tasks. It is not a long running builds, more like 1 build a second.
Sometimes I'd see 10 "Build workspace" tasks sleeping and waiting in the Progress tab.
I'd like to know what is triggering those builds. I have many plugins installed.
What is the way to troubleshoot this?
Here are some steps to help you debug what is going on.
Download the Eclipse Classic SDK for whatever version of Eclipse you are currently using. For Juno that link is here.
Open the eclipse.ini for your current normal eclipse and add the following options: -Xdebug
-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000
Start your Eclipse instance that you want to debug, it should pause at the splash screen
Unzip the Eclipse classic SDK and start that Eclipse instance
Open the Plugins view
Find org.eclipse.core.resources
Right click and select "Add to Java Search"
Open Type dialog, type in "BuildManager"
You should see a class from that plugin be given as an option, then open it
Find the line that looks like: prereqs = currentBuilder.build(trigger, args, monitor); It should be about line 728 (For Eclipse Juno)
Set a breakpoint here
Create a new Remote Java Application debug configuration and point to localhost port 8000
Launch this debug configuration
You should see your other Eclipse instance startup
Now every time the Eclipse build manager fires off a build (which should happen on all of those Build Workspace jobs), then you will see this breakpoint be hit and you can find out what builder is firing.
Update 1
If you need source to other Eclipse bundles they can also be added in the "Plug-ins" view. Select all the plugins there and right-click and use Add to Java Search
What plugins do you have installed that are currently active?
Press CTRL+3 type "plugin" and then choose plugin registry.
In the plugin view right click and choose "Active Only"
Check the non-essential core plugins (for example related to servers which automatically build & publish)
Post a screenshot of active plugins if you need any more help
You may have build automatically checked which will build when you save. Check under the nav Project > Build Automatically
Other way to close all unused projects.
Further, for good view, use filtering: View Menu -> filters -> Check 'Closed Project'.
Sometimes if you have > 20 opened projects you can observe constant 'build workspace' tendency.
I know I can look at the Preferences dialog box, but when comparing a broken build with a working one I would like to diff the files.
So where does eclipse keep its ant settings stored. I am specifically interested in the global settings.
Running Eclipse Version: Indigo Release Build id: 20110615-0604
Look into your workspace\.metadata directory and search for *.launch. These are the launch configurations including ant.
Launch configurations (including those for Ant) can be kept in the workspace by selecting "Save as - Shared File" in the "Common" tab in the launch configuration editor.
The file is
workspace.metadata.plugins\org.eclipse.core.runtime.settings\org.eclipse.ant.core.prefs
When I used previous versions of Eclipse (e.g. Ganymede/Europa) if I had edited a file and then attempted a build Eclipse would prompt me to save first.
Since I updated to Galileo (Build id: 20090920-1017 & just checked for updates) when I build I'm not prompted to save first. Perhaps the dialog had a checkbox for "don't tell me again" which I mistakenly checked on???
I figure it is just a preference setting some where but I can't seem to find it, search in Preferences for 'save' and for 'build' but did not find it. I tried "Save automatically before build" but that actually did not work for me, and isn't really what I was looking for anyways.
Any ideas?
thanks.
Edit: I'm actually using an Ant script to 'build' (right click on script and Run As...Ant Build). So perhaps my original wording was a bit off base since I did not state how I was building.
It's under Window -> Preferences -> General -> Workspace -> Save automatically before build. This works for me if I'm doing an Eclipse build (Project -> Build All). Is that how you're building?
As mention in this thread, the only other options (other than the "Save automatically before build") which actually prompt for the user for file saving are:
> Run/Debug > Launching > Save required dirty editors before launching
> Run/Debug > Launching > [x] Build (if required) before launching
Answer of VonC looks great, but does not work as it seems (Eclipse 3.5.1.R35x_v20090910 on WinXP-Pro-32). However Eclipse and I seem to think differently about what is a "required dirty editor" :-( --
Would be nice if it would be possible to define a scope of resources to check for dirtyness for every single launch configuration -- with "containing project & refernced projects" as the default setting.
But it looks like 3.5.2 fixes this problem.