Description Stefan Xenos 2005-03-30 15:03:27 EST

I use Eclipse with OptimizeIt for profiling. I am continually creating launch
configurations to pass the right command-line arguments, environment variables,
etc. to optimize it.

ENHANCEMENT 1: Allow launch configurations to be exported.

- Provide some way to export a launch configuration in a form which could be
imported into another workspace.

- Make the export format easy to create, such that 3rd-party vendors (such as
OptimizeIt) could ship their product with an importable launch configuration
that picks up all the right libraries, and all I need to do is select the name
of my app and its arguments.


ENHANCEMENT 2: Rather than including all options in the launch config, separate
the concerns.

Right now, each launch configuration directly contains all options I need to
launch my app, but I may want to reuse different subsets of options. For
example, whenever I launch an SWT app I need to provide a certain DLL, whenever
I launch with OptimizeIt I need to include certain VM arguments and additional
environment variables, etc... and whenever I'm launching a certain app, I need
to include certain dependencies on the classpath.

It would be nice if these different concerns could be configured independently.
This is, if there was a way for me to describe the following rules (in a form
which could be reused and exported):
- SWT apps are a type of java application. Here's how to launch an SWT app on a
local VM.
- java apps can be launched with OptimizeIt. Here's a template that describes
how to launch a java app on a local VM.
- Program A is an SWT application with the following dependencies.

Configuring these things independently could greatly simplify the launch
configuration dialog. A launch configuration for a Java Application would only
need to contain 1 page with 4 fields:
- Which application to execute
- What program arguments to pass in
- What working directory to use
- Which "device" to run on (I'm using the term "device" to indicate where the
program will be launched. 

A particular VM running on the local machine might be one kind of device that
can run Java Applications and Eclipse Applications from the local machine, but
it should also be possible for 3rd party plugins to supply devices that run
midlets on a cellphone or emulator, java applications on a remote machine, etc.)

The remaining launch configuration options (classpath, VM args, source
directory, JRE, plugins, etc.) would be a function of which application I'm
launching and what device I'm launching it on.

For example, I could supply my OptimizeIt options by declaring OptimizeIt as a
device that passes additional arguments to a local VM. I could then use
OptimizeIt to launch any Java Application or Eclipse Application by telling it
to run on the OptimizeIt device.

If I'm launching an SWT app, I would simply declare that my application requires
SWT and allow the device to resolve the dependency. I (the user) would have
configured the local VM to resolve the SWT dependency by adding a particular DLL
to the command-line. A remote device (cellphone, etc.) would either take the
appropriate steps to resolve the requirement for SWT or report back that it is
incapable of launching SWT apps. Similarly, downstream products that support
alternative JCLs could declare the JCL as a type of dependency.

Including this device abstraction would simplify the launching UI in Eclipse (In
most cases, the user would never need to see the classpath, environment, or JRE
tabs), and would greatly simply the UI for downstream products (like WSDD) that
support embedded development. 

I guess this is just a rambling wishlist for new launching features. Hopefully
someone finds some part of this inspiring. :-)