Ticket #1024 (closed enhancement: moved)
Opened 2012-02-27T17:04:30-06:00
Last modified 2013-04-15T09:58:52-05:00
File>New>Plugin (Eclipse)
| Reported by: | dscho | Owned by: | dscho |
|---|---|---|---|
| Priority: | major | Milestone: | imagej2-b11-docs |
| Component: | Plugins | Version: | |
| Severity: | minor | Keywords: | |
| Cc: | Blocked By: | #1351 | |
| Blocking: | #1207 |
Description
Eclipse seems to become more and more popular these days. So, to make things easier for developers, add a plugin that sets up an Eclipse project to develop an IJ2 plugin. This entails:
- a wizard-like user interface
- discovering/asking for the location of Eclipse (and remembering it via Preferences)
- setting up the directory structure
- activating the annotation processing (see #1023)
- adding an appropriate Run configuration
We might be able to come up with way to "listen" for an event sent by the Run configuration that triggers
- setting up a new class loader
- loading the classes compiled by Eclipse
- running the plugin
- giving feedback via the established connection about exceptions/failures/success
Eclipse provides quite powerful debugging facilities. This most likely requires ImageJ's to be started in a special mode listening for debuggers (which we could even store in ImageJ.cfg so that any subsequent restart of ImageJ activates that mode), but we might not be able to benefit from Eclipse's in-place code-replacing.
So: even if we manage to come up with a Run configuration that will run the plugin in the current ImageJ instance, we will most probably need to come up with a standalone Run and Debug configuration (that starts up ImageJ whereever it might be installed, adding the appropriate classpath so the plugin is discovered, possibly loading certain images -- that might be chosen from the list of open images at the time File>New>Plugin (Eclipse) is run -- and then runs the plugin).
As a consequence, we need to teach imagej.Main to sprout a way to open images and call plugins from the command-line. The appropriate place is AbstractUserInterface's processArgs() method (whose javadoc should then contain the note that subclasses overriding that method need to hand off to AbstractUserInterface to handle the default command-line parameters).
Change History
comment:2 Changed 2012-06-05T15:30:12-05:00 by curtis
- Milestone changed from imagej-2.0.0 to imagej-2.0.0-beta4
comment:4 Changed 2012-09-06T19:02:22-05:00 by dscho
- Milestone changed from imagej-2.0.0-beta4 to imagej-2.0.0-beta5
comment:5 Changed 2012-09-13T13:34:14-05:00 by curtis
Note that the UIService#processArgs(String...) method has moved to a dedicated ConsoleService now (also part of ij-app). And I agree that adding these debugging hooks as DefaultConsoleService options is definitely the right way to go! Though we probably want to have a DebugService which the ConsoleService merely configures as it is told via command line args.
comment:6 Changed 2012-10-02T13:44:37-05:00 by dscho
This minimal Beanshell script shows how to start Eclipse from within a Java application:
import java.io.File;
eclipseRoot = new File(System.getProperty("user.home") + "/eclipse/");
addClassPath(new File(eclipseRoot, "plugins/org.eclipse.osgi_3.7.2.v20120110-1415.jar").getPath());
/*
for (File file : new File(eclipseRoot, "plugins").listFiles())
if (file.getName().endsWith(".jar"))
addClassPath(file.getAbsolutePath());
else if (file.isDirectory())
for (File file2 : file.listFiles())
if (file2.getName().endsWith(".jar"))
addClassPath(file2.getAbsolutePath());
*/
import org.eclipse.core.runtime.adaptor.EclipseStarter;
import java.util.HashMap;
import java.util.Map;
Map properties = new HashMap();
properties.put("osgi.install.area", eclipseRoot.getPath());
properties.put("osgi.syspath", eclipseRoot.getPath() + "/plugins");
properties.put("osgi.configuration.area", eclipseRoot.getPath() + "/configuration");
properties.put("osgi.parentClassloader", "fwk");
EclipseStarter.setInitialProperties(properties );
EclipseStarter.startup(new String[] {}, null);
c = EclipseStarter.run(null);
print(c);
// TODO: EclipseStarter.shutdown();
To import the Maven project, something similar to
eclipse -nosplash
-application org.eclipse.cdt.managedbuilder.core.headlessbuild
-import {[uri:/]/path/to/project}
-build {project_name | all}
-cleanBuild {projec_name | all}
might work.
comment:7 Changed 2012-10-02T14:04:08-05:00 by dscho
Most likely something like this should work for importing the Maven project:
import org.eclipse.m2e.core.MavenPlugin;
List<IMavenProjectImportResult> results =
MavenPlugin.getProjectConfigurationManager().importProjects(
projects, importConfiguration, monitor);
comment:8 Changed 2013-01-22T15:14:43-06:00 by bdezonia
- Milestone changed from imagej2-b7-ndim-data to imagej2-unscheduled
comment:9 Changed 2013-04-04T10:34:44-05:00 by curtis
The Icy team has created a plugin Icy4Eclipse that eases development of Icy and Icy plugins within Eclipse.
comment:10 Changed 2013-04-15T09:58:52-05:00 by curtis
- Milestone changed from imagej2-unscheduled to imagej2-b11-docs
comment:10 Changed 2014-05-01T06:00:28-05:00 by curtis
- Status changed from new to closed
- Resolution set to moved
Migrated to https://github.com/imagej/imagej/issues/63