I’ve been playing around with PushButtonEngine and Flash over the last couple of days, and though it may be useful to document how I’ve hooked this up to my existing Eclipse install.

I’ve started off with a fairly vanilla Eclipse Java installation, v3.4.2, with the subversion plug-ins and Oxygen XML for eclipse. The 2 options that I’ve looked at for Flash development are

• AXDT - an open source plug-in; and

• FDT - a commercial offering from a company in Germany.

I’m going with FDT at the moment as it seems much more feature complete, it comes with a 30-day trial period so I guess I’ll have to decide if it’s worth the money after that, the biggest problems it has are a lack of documentation and poor support from the parent company, on the upside there seems to be a vibrant and helpful community of users. It’s also massively overpriced, but that seems to be par for the course with small German software vendors (EJ Technologies, I’m looking at you…).

I’m using the the build files described in a previous post, and have set up a custom schema for editing PBE level files.

The other neat tool that I’ve found is the Monster Debugger, which has a nice logging UI and the ability to inspect objects at run-time, it can also dynamically invoke methods, to a fairly limited extent (Flash IDE’s are about 30 years behind Lisp in this respect, even the JVM can do limited hot code replacement).

I should probably do a round up of useful links as well, as the Flash community in general seems to be really helpful and there’s loads of good stuff out there.

Just in time for Christmas, Tom Copeland has announced a new release of PMD with some notable speed increases. Hopefully this will make it fast enough to use the Eclipse plug-in in regular development, rather than having a separate ‘analysis’ phase to clean up any warts before each release.

Just a quick note so that it gets into the Google help engine. By default the copy of Ant that is included with Eclipse does not reference it’s own internal copy of JUnit on it’s class path, to change this open up the preferences window (hit command-comma if you’re on a Mac) and open the Ant/Runtime node then add the JUnit location to the global path. If you’re doing full-source editing (which is highly recommended for all Eclipse users!) then you can just add a workspace reference and it will work fine.

In Eclipse your plug-ins normally have their classpath’s based upon their dependencies. I’m playing around with an RCP based application that will need to reference external libraries to avoid onerous licensing requirements. Here’s the somewhat convoluted code required to do this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

Context getContext() {
	if (context != null) { return context; }
	final Properties props = new Properties();
	props.put(Context.INITIAL_CONTEXT_FACTORY, getInitialContextFactory());
	props.put(Context.PROVIDER_URL, getProviderURL());
	props.put(Context.SECURITY_PRINCIPAL, getDirectoryPrincipal());
	props.put(Context.SECURITY_CREDENTIALS, getDirectoryCredentials());
	URL[] classpath = null;
	Plugin plugin = JmsPlugin.getPlugin();
	try {
		String stringList = plugin.getPluginPreferences().getString(PreferencesInitializer.CLASS_PATH);
		StringTokenizer st = new StringTokenizer(stringList, File.pathSeparator);
		ArrayList v = new ArrayList();
		while (st.hasMoreElements()) {
			v.add(new URL("file://" + st.nextElement()));
		}
		classpath = (URL[]) v.toArray(new URL[v.size()]);
	} catch (MalformedURLException e) {
		String msg = e.getMessage();
		Debug.error(plugin, 0, msg != null ? msg : "", e);
		throw new RuntimeException(e);
	}
	ClassLoader oldClassLoader = Thread.currentThread().getContextClassLoader();
	ClassLoader newClassLoader = new URLClassLoader(classpath, getClass().getClassLoader());
	try {
		Thread.currentThread().setContextClassLoader(newClassLoader);
		context = new InitialDirContext(props);
	} catch (NamingException e) {
		String msg = e.getMessage();
		Debug.error(plugin, 0, msg != null ? msg : "", e);
		throw new RuntimeException(e);
	} finally {
		Thread.currentThread().setContextClassLoader(oldClassLoader);
	}
	return context;
}

The relevant code is in the first try... catch block. Then I can have this plug-in rely on a second plug in which includes the JMS interfaces only, and have a preference page which allows the user to select a third party JMS provider by URL. At the moment it won’t handle JMS providers that reply on native methods, but that could be fixed the same way if needed. The Debug.error(...) is just a utility class to log an Eclipse IStatus.ERROR message. As an added benefit of this approach, because I use the latest API version in my JMS plugin, I can check for a JMS version at runtime using the metadata returned by Connection.getMetaData() and then only call JMS 1.1 supplied methods when they are available.

After playing around with Lisp for a few days I’ve diverted myself back to a small Java project. Almost immediately I’m missing the Lisp environment! To be sure there are some things that I prefer about my Java environment, which is Eclipse, but I just miss having an interactive top-level so much! It’s just amazingly convenient to be able to try sunning a fragment of code, and the ability to tweak it and try again if you hit any problems is such a productvity boost.

Recently in the Eclipse news group there’s been a lot of complaints about the new widget style that is now the default in mlilestone 8. Many people are saying that the new widgets are bad because they are emulated in Java, and not real native widgets at all. This seems really odd to me in some ways, since the widgets have always been emulated in Java, it’s not llike this is some new thing that’s been sprung upon us by the developers.

But then in other ways I’m not surprised, because for all Eclipse’s touted native look and feel it’s always really been a Windows application. Compare the new Eclipse widgets with those of a native Gnome application (GEdit in this case) and you’ll see at once that they look out of place. But this has always been the case. The real solution surely, is to use genuine native widgets here. The only reason the Windows crowd are screaming now is that Eclipse is becoming more cross platform in it’s look and feel, not less.

Has been released, get it from the usual place. Initial impressions are that the new look and feel has been cleaned up and much improved. I found the last release a little buggy (under Linux GTK) so hopefully this will be more stable.

Talk of merging Eclipse and NetBeans is off then, according to this recent post. I can’t say that I’m surprised, since many of the differences between the two ‘platforms’ have become religious issues.

What I’d like to see, however, is soome commonality and code sharing between the two where it makes sense. For example in the resource management / virtual file system APIs, or their action API. This kind of thing would make writing plugins that work with multiple IDEs much easier, and would avoid duplication of effort, allowing the developers to enhance the two products in new ways.