Looks like with eclipse 3.6 that does not work anymore, I was not able to actually use a JAR file as location like I used to set this up with eclipse 3.4.
So I’m directly associating the AMQ namespace with the XML schema available from the AMQ project.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:context="http://www.springframework.org/schema/context"
	xmlns:jms="http://www.springframework.org/schema/jms"
	xmlns:p="http://www.springframework.org/schema/p"
	xmlns:amq="http://activemq.apache.org/schema/core"

	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
		http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
		http://www.springframework.org/schema/jms http://www.springframework.org/schema/jms/spring-jms.xsd
		http://activemq.apache.org/schema/core http://activemq.apache.org/schema/core/activemq-core.xsd">

	<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"
		p:locations="classpath:jms.properties">
	</bean>
	<amq:broker useJmx="true" persistent="false">
		<amq:transportConnectors>
			<amq:transportConnector uri="${amq.brokerURL}" />
		</amq:transportConnectors>
	</amq:broker>
</beans>

Go to the eclipse XML catalog editor and add a custom entry:

Location: http://activemq.apache.org/schema/core/activemq-core-5.4.1.xsd
Key type: Schema location
Key: http://activemq.apache.org/schema/core/activemq-core.xsd

Here I briefly show some of the many features that I like:

Install New Software

I believe with eclipse 3.4 the user interface for updating/installing plugins has been pretty much messed up. Seems the eclipse engineers have done a good job to fix it up again. It has never been so easy and intuitive (with drag & drop support for update-site URLs) to install and update an eclipse plugin. But even more important, now it is possible to export bookmarks of your favourite plugins (you can select them plugin by plugin) and import them into another eclipse installation (e.g. for switching to a new eclipse release).

Type Filter (eclipse 3.4)

With a large number of libraries in the classpath it gets pretty overloaded in the type search dialogs. Mostly you find lots of classes that you never want to deal with directly. E.g. classes from the com.sun.* packages. Still you have to skip over them while searching for some other classes.
By defining a type filter you can suppress any package you are not interested in.

toString() Method

I usually would use the ToStringBuilder from the Apache commons-lang package to implement any toString() method.
As of eclipse 3.5 the Source->generate toString()… feature can be customized to support the commons-lang ToStringBuilder pattern.

Format edited lines only (eclipse 3.4)

In a team environment it is important that everybody is using the same formatting rules for auto-formatting the source code. Otherwise code comparison / mergeing can get pretty nasty. However sometimes this is not the case. Still eclipse can help to minimize the impact of autoformatting. You can choose the option to format only the code portion that has been actually changed.

Breadcrumbs (eclipse 3.4)

Eclipse has always had a perspective called Java Browsing (some heritage from good old Visual Age). I never really liked it, as it consumes quite a lot of space of the workbench.
With eclipse 3.4 the eclipse team introduced the so called breadcrumbs (Alt-Shift-B) which is showing almost they same information but much is more compact. It allows you to quickly jump between packages, classes, members, etc.

Block selection

Alt-Shift-A activates a special editing mode where it is possible to select any rectangular text area and copy / paste it.

An example for registering a schema in a jar:

Location: jar:file:D:/workspace/mvn-repositories/local/org/apache/activemq/activemq-core/5.1.0/activemq-core-5.1.0.jar!/activemq.xsd
Key Type: Schema Location
Key: http://activemq.apache.org/schema/core/activemq-core.xsd

Anyway here is how to fix it. Let’s say we have a web project A and a utility project B. You face the situation that project B does not show up as JavaEE module dependency. Open B in the navigator view (so you can see all the metadata files .project, .settings/… etc.).
Look for a file .settings/org.eclipse.wst.common.component! Does it exist? If no just create it, its contents should be like

Next check the .project file

	PROJECTNAME
	

	
	
		
			org.eclipse.wst.common.project.facet.core.builder
			
			
		
		
			org.eclipse.jdt.core.javabuilder
			
			
		
		
			org.maven.ide.eclipse.maven2Builder
			
			
		
		
			org.eclipse.wst.validation.validationbuilder
			
			
		
	
	
		org.eclipse.jdt.core.javanature
		org.maven.ide.eclipse.maven2Nature
		org.eclipse.jem.workbench.JavaEMFNature
		org.eclipse.wst.common.project.facet.core.nature
		org.eclipse.wst.common.modulecore.ModuleCoreNature
	

In my case the file was missing some builders (should not be relevant for the bug)

• org.maven.ide.eclipse.maven2Builder
• org.eclipse.wst.validation.validationbuilder

and some natures (these really hurt)

• org.eclipse.wst.common.modulecore.ModuleCoreNature
• org.eclipse.jem.workbench.JavaEMFNature

I am absolutely convinced that source code must be formatted according to rules a team agrees on. Therefore I have my Save Actions setup for auto-formatting my code (by the way I just rely on the eclipse built-in rules, I would only adjust the line length to 120) every time it is saved.
For those whow often need to fix/change unformatted code (code that is not auto formatted at all) are going nuts. Once you start comparing with older revisions you can’t actually tell anymore what exactly you have modified, the auto-formatter has done a damn good job!
So now you can set an option that only formats actually modified lines code.

	@ManagedOperation(description = "Get the logging level for a category")
	@ManagedOperationParameters( { @ManagedOperationParameter(name = "category", description = "Logger category"), })
	public String getLoggerLevel(String category) {
		return LogManager.getLogger(category).getLevel().toString();
	}

After reporting this a a eclipse JDT bug I was pointed at that this is allowed syntax (see JLS) but the sun compiler does not properly implement syntax checking! So I should rather see to report this against the Sun compiler. Still it is strange that this syntax is allowed at all!!!

Importing a WAR file gets you a special folder ImportedClasses which is supposed to contain the package/folder structure for imported classes. Due to a bug in the eclipse WAR importer they are copied to ImportedClasses/WEB-INF/classes. As a result, starting a deployed web application presents plenty of ClassNotFoundExceptions and the like.

Today I tried this again with eclipse 3.4-M4 and was glad to see this bug fixed, I was already preparing to file a bug. Until 3.4 is released the classes must be moved manually to the right folder!