I’ve just released a new version of my Eclipse plugin called JUnitLaunchFixer. If you’ve never heard of it, it lets you set the default heap size for new debug launchers in Eclipse. You can read more about it in the original announcement. This new version fixes a bug that caused it not to accept new parameters in one case, and it also adds the ability to set a default for the maximum permgen size, which is something I’d been wanting to add for a while.
If you already have it installed, go to Help>Check for Updates in Eclipse, and you’ll see it. If you don’t have it installed, the update site is here:
My friend Chris and I both work for the same company. Our product has around 900 JUnit tests, and for some of them, the default heap size that Eclipse runs JUnit tests with has become too small. You can change the heap size on individual JUnit launchers, but if you have lots of tests, this gets tedious. It also means that you have to run a test, see if it runs out of heap, change the setting and then rerun the test. We both thought there had to be a better way.
We were wrong. There is apparently no way within Eclipse to set a default heap size for JUnit launchers, which means you have to set them individually. We don’t like that.
Thus, JUnitLaunchFixer was born. This is an Eclipse plugin that will set the max heap size on a JUnit launcher when it is created to a value you have previously specified in the plugin preferences. The default is 1G, but you can tailor it to whatever you want. The first time you start Eclipse after installing the plugin, you will be presented with a selectable list of launchers that you can update, and a chance to set the default heap size. You can select as many or as few as you want. This will only be run once, unless you ask for it to run again by setting a preference.
JUnitLaunchFixer is released under the Eclipse Public License. It’s an open source project, so if there’s something you’d like to see it do, or you want to help out, let us know.
As of this moment, it’s only been tested with Eclipse Ganymede (3.4) on Windows 7 and Snow Leopard. I will be testing with Europa and Galileo soon.
You can download the source and build it yourself, but we also have an Eclipse update site to easily install it from http://junitlaunchfixer.googlecode.com/svn/trunk/JUnitLaunchFixer-update-site/
Is anyone familar with the format of the files in .metadata/.plugins/org.eclipse.core.resources/.projects in the workspace of Eclipse 3.0? I have an Ant task that uses the .classpath file of a project, along with the JDT preferences to build an Ant classpath for a project with an external build file, and I’m now trying to support projects that depend on other projects. I can see from the .classpath file which projects are referenced, either as a “src” type or a “lib” type, depending on how you added it, but I need to actually FIND those projects and get their build info.
I poked around in my workspace and discovered the directory I mentioned above. For each project that Eclipse knows about there is a subdirectory for it. Inside each subdirectory is a file called .location. I can see by looking at this file with a hex editor, that it does indeed contain the full path to the project. But it’s a binary file, and I don’t know the format. Is it documented anywhere?
I also did a little poking around the Eclipse API. I found a ResourcePlugin which sounded useful, but experiments from within Jython were fruitless. I would also like to avoid hooking into the Eclipse API since I’m trying to support multiple versions of Eclipse, but if that’s the only way to get to the data, I’ll do it.
The question, then, can be broken down into three subparts:
- Does anyone know the file formats?
- Does anyone have a code snippet of using the proper Eclipse API outside of Eclipse to get to the info in those files?
- Does anyone have a better solution to this problem?
Since I’ve taken down the writeback feature of this blog, thanks to certain miscreants, if you have a suggestion, please email it to email@example.com. Thanks.
I just got the notice that Eclipse 3.0 M2 is now available. I’ve already been using 3.0, but judging by the release notes there’s a lot of chewy Eclipse goodness loaded in this release. I’ve already downloaded it and “installed” it, such as it is. I’ve upgrading my JDK to 1.4.2 and will fire the new Eclipse up shortly.
Update: OK, I’ve got M2 and JDK 1.4.2 installed. While it does monopolize my CPU on startup, once up it is fast! And there are lots of spiffy new features. My favorites so far are the JavaDoc and Declaration views. The JavaDoc view shows the javadoc for the selected method and the declaration view shows the declaration. Clicking on the “println” part of System.out.println results in the javadoc or the source code being shown, depending on which view is selected. Another feature, which mimics something that is in the new IntelliJ is a change indicator in the gutter on lines that you’ve changed in this editing session. Hovering over the marker shows what the line looked like before and allows you to revert changes. Very nice, indeed!
I have but one complaint about the latest release of my favorite IDE, Eclipse. Everyone who uses Eclipse knows that to close an editor you click on the little ‘X’ button on the right side of the editor’s tab. But for the past several months there’s been another way: Control-Click anywhere on the tab. (You can also Ctrl-F4.) The Ctrl-Click struck me as odd when I first read about it, but I’ve come to do it reflexively. Now they’ve taken it away!!! I don’t know why, but they did. And I’m not happy about it… I keep Ctrl-clicking on those tabs and they just don’t go anywhere now…
The latest build of Eclipse has re-added a feature that I had been missing since the M4 or so. This feature is a linking of location between the Package view and the current editor. You’ve always been able to double-click on a class in the package explorer and have it bring that class up in the editor. What you used to be able to do, and what you can do again, is to have the package view updated based on your location. So if I’m editing Foo and then I click on the tab for Bar, the package view will now show that I’m in Bar. This is now a toggle instead of being foisted upon those who don’t like it. If you install this latest version (remember to do it like this) you’ll now see a little icon on the top of the package explorer that looks like this
I’m really glad this is back because I missed it. But I’m also glad that there’s a toggle switch because there were times that this behavior was a real pain.
Man, I love Eclipse more and more every day. I’ve been using it for almost a year and it just keeps getting better. The fabulous Eclipse team released Eclipse 2.1 M5 a couple of hours ago and I fetched it shortly thereafter. Wanna know how the install went?
- I shut down the instance I had running
- Squirreled away trusty M4 version for safe-keeping
- Unzipped the M5 distro
- Copied my workspace folder from M4 to M5
- Copied my plugins over from M4
- Fired up the new version
Why can’t all installs be that easy?
If you are an Eclipse user, think about getting this version. There are quite a few tasty new features lurking about in there.
I got this from James Strachan‘s blog. It’s about how you can have Maven generate the .project and .classpath files in order to have Eclipse auto-grok your project!
You can define this property a local build.properties, in the build.properties in your home directory or on the command line via -DpropertyName=value in the following command.
Then to update your eclipse installation so that its aware of the Maven repository, type the following.
Now once you’ve configured your Eclipse installation, you can just cd into any of your maven-enabled projects directories and type
and Maven will create a .project and .classpath for you!
Here‘s the full article. I’m a huge fan of Eclipse, and as I said before Maven was something I’d been meaning to look into. This adds another reason to look at it.