Maybe more than one page.


Lots of people use Eclipse. We would like to make it very easy for them to try out NetBeans for a day.

Many of these people will want to try NetBeans on real code, not just toy projects; and we want them to be able to choose to continue using NetBeans some or all of the time, even while some of their colleagues may still be using Eclipse.

If these people have existing projects, they might use Maven or some other system that NetBeans can recognize directly, but often they will just have Eclipse project metadata. This consists at a minimum of .project and .classpath files, sometimes other files, and projects may live inside a workspace with additional information.

Currently we can "import" some very simple Eclipse projects/workspaces (only elementary classpath information is understood), but this really makes a new NetBeans Ant project based on the snapshot of the Eclipse metadata at the time of import. The extra files for the NetBeans Ant project can be a burden, and there is no synchronization with the Eclipse metadata, so this is not a very attractive option. (Compare to EclipseProjectImportOnePager.)

Ideally we could "just" open an Eclipse project directly. No additional NetBeans-specific files would be saved anywhere in the project, and any customizations to project configuration made through the NetBeans GUI would be saved in Eclipse's own format. This would make it feasible for some, but not all, members of a development team to use NetBeans. It would also make it feasible for one developer to use both IDEs: for example, NetBeans for GUI building and profiling, Eclipse for Mylyn and code formatting.

Under the Hood

Most IDEs, Eclipse included, have a single project type with some optional natures or aspects. Generally they have more or less rigid ways of storing project metadata.

NetBeans, by contrast, has a full SPI for project types. This is what allows it to have native Maven support. By the same token, it should be able to directly support Eclipse metadata as a native project type.

A nice effect is that it should be possible to simply use Open Project to open an Eclipse project. There is no need for an explicit conversion or import.

Reading Eclipse metadata

This part is probably not too hard. The various SPIs for projects allow them to report information (display name, location of sources, classpath, appearance...) however they like. An Eclipse project would read and interpret .project, .classpath, and other files for this information.

Writing Eclipse metadata

By the same token, an Eclipse project could have a Properties dialog which permits the user to change some of this metadata from inside NetBeans. Changes would be written to files that Eclipse would understand.

There is no requirement to permit every piece of Eclipse metadata to be changed through the NetBeans GUI; only those parts which are interpreted by NetBeans, and important enough to be edited on a routine basis: basic classpath, etc. For everything else, the user can always make changes in the Eclipse IDE.

Project vs. workspace

Eclipse projects are usually contained in a workspace, which defines additional metadata, such as defaults for project settings, or locations of libraries.

It may be useful to open "naked" projects, as these can sometimes be found e.g. in popular open-source projects. Nevertheless, the core use case of this feature is to open projects found in a workspace.

Building, testing, debugging, deploying...

Various actions are sensible to perform on a project:

  • build (compile, package, ...)
  • test (JUnit, ...)
  • run (debug, profile, ...)
  • deploy (to a Java EE server, ...)

Eclipse implements these actions using a combination of builders, run configurations, and miscellaneous menu items. NetBeans offers these actions as standard fixtures of the GUI which are bound by the project to concrete implementations. For Ant-based projects, these are usually just Ant targets.

For NetBeans to support such actions on Eclipse projects will take some work. Running a hidden Ant script with appropriate parameters is possible (and would allow reuse of a lot of Ant loggers for stack traces, JUnit, etc.), but seems clumsy. Or the IDE could directly implement appropriate actions.

For the case of building, one interesting possibility is to read the list of builders configured in .project and actually invoke them directly. Eclipse builders are generally written to have minimal dependencies (so they can be run in headless mode as well as from the IDE). NetBeans could in principle load the necessary builder code directly from an Eclipse installation and invoke it. This would ensure that even exotic build steps would be supported out of the box.

The Java builder should probably not be used, since the NetBeans javac would do this part. CompileOnSave is relevant here.


Eclipse projects can have various natures supplied by plug-ins. Supporting them all is impossible; supporting even many will be a challenge. Natures might add implicit classpath entries, builders, and much more. We need to determine which project-related plug-ins are critical to support.

(As previously mentioned, it might be possible to sidestep this issue in the special case of builders.)


Obviously Eclipse is not a "competitor" in this space (and to my knowledge it makes no effort to import metadata from other IDEs).

IDEA does a passable job of opening Eclipse projects (you need to go through a special import wizard). It adds some IDEA-specific metadata files, but can share .classpath. We could probably do better for NetBeans.

Feature Priorities

  • Setup
  • (P1) Can open an Eclipse project (e.g. dir containing .project) using just Open Project.
  • (P1) Project in a workspace supported.
  • (P3) Project outside any workspace supported.
  • (P3) Can open an Eclipse workspace dir as a kind of container project.
  • (P3) Can create a brand new Eclipse project with appropriate metadata.
  • Classpath
  • (P1) Can read .classpath for basic classpath information, e.g. to be used in code completion or background compilation.
  • (P2) Understand Eclipse JRE classpath volume type and map to NetBeans Java platform somehow.
  • (P3) Understand exotic volume types coming from plug-ins.
  • (P1) Can add basic classpath entries (JARs, libs, subprojects) using some GUI (Properties dialog, Libraries node).
  • (P1) Can remove or reorder classpath entries using some GUI.
  • (P1) Changes to classpath written back to .classpath.
  • (P3) ...without reformatting unrelated parts of the file.
  • (P1) Understands build output directory(ies) of project.
  • (P3) Can change output location using GUI.
  • (P1) JSP classpath correct in web applications.
  • (P2) Tag libraries are offered in code completion.
  • Source roots
  • (P1) Finds all the Java source roots in the project.
  • (P2) Knows which ones are unit tests and handles them appropriately (e.g. for Go to Test).
  • (P2) Knows which NetBeans template categories are appropriate to offer.
  • Projects window display
  • (P1) Displays all Java source roots in package structure.
  • (P1) Displays any Java EE document roots.
  • (P2) Displays any Java EE deployment descriptors (to be opened using structure editors).
  • (P2) Displays Libraries node with classpath information.
  • (P1) Shows annotations (e.g. icon badging) based on VCS status.
  • (P1) Permits Find in Files to work.
  • (P1) Permits Show Document in Projects to work.
  • Actions
  • (P1) Can compile some or all classes in the project, perhaps using internal javac.
  • (P2) Can customize compiler options (at least those supported by javac).
  • (P2) Can create Javadoc.
  • (P3) Can customize Javadoc generation options.
  • (P2) Can create a JAR.
  • (P3) Can create more exotic packagings as defined by builders in Eclipse plug-ins.
  • (P1) Can run a class with a main method.
  • (P2) Can create run configurations for multiple such classes.
  • (P1) Stack traces in output are hyperlinked.
  • (P1) Console I/O works.
  • (P1) Can configure a special classpath for running, extra VM args, etc.
  • (P1) Can run JUnit tests.
  • (P1) ...and display results in the JUnit Results window.
  • (P2) or JUnit 4.x tests.
  • (P3) or TestNG tests.
  • (P1) Can run all tests in project.
  • (P3) Can run individual test methods.
  • (P3) Can re-run failed tests.
  • (P1) Can debug main classes or tests.
  • (P1) Including Step Into and JPDA reload.
  • (P1) Can profile main classes or tests.
  • (P2) Can deploy Java EE apps to a server. (TBD what all this involves)
  • Special technologies
  • (P3) JavaWebStart packaging and execution supported.
  • (P3) Applet execution supported.
  • Editor
  • (P2) Code formatting picked up from Eclipse settings.
  • (P3) Templates, abbreviations, etc. picked up from Eclipse settings.

There is probably a lot of Java EE functionality missing from the above list, due to ignorance rather than intent. E.g. does anything special need to be done to support web service injection? Application validation? In-place deployment? Database binding with JPA?

Expected Limitations

Native Eclipse projects are not likely to be as complete in features as NetBeans Ant projects. Some IDE features are simply done at the project level in a way that cannot be easily ported to other project types. These features need to be identified and explicitly waived.

There is no plan to provide Java ME functionality in Eclipse projects. Anyway ME applications are usually small enough that they can be created from scratch (so cross-IDE support is less of a concern), and NetBeans is probably the best IDE for ME development to begin with (so we would be attracting fewer users).

Not all IDE setup may be imported; for example, Java EE server configuration might not translate well.


TBD. Need a minimum of one full-time developer for a release cycle for core functionality, and probably a full-time developer for Java EE functionality.



Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo