How to Make Your Java Projects Coexist in JBuilder and Eclipse Charles Overbeck and Helen Bershadskaya

Borland JBuilder R&D EngineersNovember 9, 2005

Today’s Agenda

JBuilder & Eclipse Background What Borland Strategy Means for JBuilder Users Overview of JBuilder & Eclipse Project Structures Working with Java SE Projects Working with J2EE Projects Sneak Peek at Peloton Migration Tool Q&A

JBuilder & Eclipse Background

JBuilder is written on top of Primetime, an IDE infrastructure developed by Borland

JBuilder uses Swing Eclipse is a new open source IDE infrastructure started

by IBM Eclipse uses SWT Eclipse is also a Rich Client Platform

Future of JBuilder

The next version of the Borland Java IDE, code-named Peloton, will be based on Eclipse

Borland does not want to compete with the open source community in core IDE feature areas, such as compiling, editing, and debugging

Borland can instead leverage existing Eclipse IDE functionality to focus on innovative solutions in other areas, such as SDO

What This Means for JBuilder users

JBuilder project settings and Eclipse project settings are stored differently

When JBuilder users upgrade to Peloton, they will want to migrate their JBuilder projects to an Eclipse-based format

Today, some shops have both Eclipse and JBuilder. Can they both coexist?

Terminology

Eclipse Project ~= JBuilder Project Eclipse Workspace ~= JBuilder Project Group + JBuilder

IDE settings IDE settings in Eclipse are typically done at a workspace-level –

if you switch workspaces, you get new settings. In JBuilder, IDE settings are global; they are not affected by what project or project group is active

JBuilder project group is narrower than Eclipse workspace. An Eclipse workspace you can view/open classes from all projects in the workspace. In JBuilder, you can only view/open classes from the active project. Eclipse workspace provides defaults for projects, e.g., the compiler settings

JBuilder can have multiple project groups open

JBuilder Project Overview

Project settings are stored in two locations: <project>.jpx (.jpr back in the day) – common settings that are

shared by all <project>.jpx.local – settings for the local user that are not

checked into VCS, that are not shared.

IDE settings stored in <userhome>/.jbuilder2006 and <userhome>/.primetime2006. For example, on Windows, C:\Documents and Settings\coverbeck\.jbuilder2006

JBuilder project group settings stored in <projectgroup>.bpgr and <projectgroup>.bpgr.local.

Eclipse Project Storage Overview

Common project settings are stored in .project and .classpath files. Plug-ins store their project-level settings in the project’s .settings directory

User- and workspace-specific settings are stored underneath the .metadata directory in the workspace.

Simple Project Coexistence Example

Demo

Java SE Projects

Both JBuilder and Eclipse “discover” source automatically

User specifies the source paths, and all Java packages and classes underneath are found by the IDEs

For “simple” editing, compiling, and debugging, there should be no problems sharing projects.

User needs to keep projects in sync, e.g., for required libraries, compiler settings, etc.

Recommend separate JBuilder classes and Eclipse bin directories for dependency checking

Java SE Projects

UI Designers JBuilder’s UI Designer and Eclipse’s VE modify source

differently JBuilder uses jbInit() method VE uses initialize() method and has certain limitations JBuilder cannot design SWT applications You must design with one or the other…

Java SE Projects

Eclipse: Use File | Export to create JARs JBuilder: Use Archive Nodes JBuilder allows multiple settings for archives to be

persisted, and allows for the creation of JARs as part of the build process

Sharing a Java SE Project

Our first choice is to exclusively use JBuilder If you have to work on a project with both JBuilder and

Eclipse, we recommend putting the .jpx and .project files in the same directory

Use Ant to produce builds that are identical on both IDE’s

You will need to manually update each project with the respective IDE, e.g., if you add a JAR to the project’s classpath

J2EE Projects - Eclipse

Eclipse uses WTP Web Tools Platform is a set of many Eclipse plugins for supporting web

and J2EE development WTP is combination of various company contributions

IBM donated some of its WSAD code Eteration donated and continued development on generic server plugin

support BEA is most recent large contributor, currently providing project facet

support

Project scope is pretty large, and so far it has been undergoing a lot of changes. .7 version shipped on July 29th, providing mostly user accessible support. 1.0 will be coming out on December 16th, providing more API level support, and more finished features.

J2EE Projects - Eclipse

J2EE Module Structures are different between JBuilder and WTP In .7 WTP attempted to support multiple modules per project, but that

didn’t really work out -- many people thought that that wasn’t the right working model, besides various implementation issues.

1.0 will have only one J2EE module per project. Each module’s structure is also different in Eclipse from JBuilder

WTP has different structures for various modules, e.g. the Web Module has a WebContent sub directory, which is what gets used for actual deployment, and a JavaSource directory which is where associated Java sources go. EJB modules have just a source subdirectory

In .7, when modules get built, the build results get copied to a .deployables subdirectory, but in 1.0 this implementation will be changed to each server plugin dealing with building files as it needs during the publishing phase.

J2EE Projects - Eclipse

For EJB development, WTP only provides annotation based support, with XDoclet being the only annotation engine currently supported. EJB 3.0 annotation support is to come later.

XDoclet annotated Java code looks like:/**

* @ejb.interface-method

*/

public Customer getCustomer() {

return customer;

}

XDoclet builder then generates necessary Java interfaces, and deployment descriptors

One problem is any modified descriptors get overwritten after the builder is run.

J2EE Projects - Eclipse

Eclipse currently does not have any visual designers for Java EE that use WTP.

Only 1-way wizards to generate EJBs. Currently WTP does not provide any help with Entity Beans -- there

is no wizard for them. 1.0 is supposed to fix that. Since all deployment descriptor code is generated from Java

annotations, there is no really helpful tool for working with DD information. There is a basic XML editor that knows about necessary pieces based on a schema or DTD, but that doesn’t help with DD information that will be generated from a Java file.

WTP will require one deployable EE artifact per project, e.g., one EJB JAR, or one web WAR, etc.

J2EE Projects -- JBuilder

JBuilder modules have a consistent and simpler structure, but it is different from what Eclipse uses, so is hard to map from one product to the other as is.

In JBuilder you can work with the wizard/designer/user generated deployment descriptors in the DD Editor, and know the data will remain in the descriptor.

Would have been good to provide XDoclet support, but never got around to it.

JBuilder can produce many artifacts for a given project, e.g., a WAR, an EJB-JAR, and an EAR

J2EE Projects -- JBuilder

JBuilder Designers provide a unified view, e.g., of an EJB bean, but behind the scenes updates Java source and deployment descriptors

JBuilder Designers are two-way -- e.g., you can work with source or designer representation and will see the same information. There are Eclipse projects under way to support this model, but only for EJB 3.0.

Since JBuilder’s designers produce non-annotated source code and descriptors, these are not compatible with WTP’s model of working with source annotations and XDoclet builder. So you cannot work with JBuilder’s designers on projects that might need to use WTP.

J2EE Projects -- JBuilder

Illustration of J2EE project code in JBuilder and Eclipse

J2EE Conclusions

Cannot work with JBuilder’s modules and WTP modules simultaneously

Cannot work with JBuilder EJB designer and WTP at the same time because of different source/descriptor information models.

While there will undoubtedly be WTP-based designers in the future, they don’t exist today, which makes JBuilder an obvious choice

Writing Eclipse Plugins

Eclipse is clearly at an advantage here

Migration

Borland will provide a migration tool to convert your JBuilder projects to Eclipse projects

Will include additional functionality to make the migration easier, such as Visibroker support

Recommended Strategy

For projects with “basic” Java features, you can work on those projects with both JBuilder and Eclipse

For Java EE projects, it will be difficult to use both IDEs For JBuilder projects, consider producing one artifact per

project, e.g., one Application JAR, or one EJB JAR, or one WAR, etc.

Consider doing builds with Ant. Continue to use JBuilder today, still the best Java IDE When upgrading to Peloton, use migration tool

Sneak Peek

Preview of Peloton importing from a JBuilder project

Summary

Today, JBuilder still the best IDE, especially for J2EE apps

Change is coming, but Borland will support its customers in making that change

Some projects can coexist between Eclipse and JBuilder For other projects, coexistence will be difficult

Q&A

Questions?