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.

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.

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.

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.