How to Make Your Java Projects Coexist in JBuilder and Eclipse Charles Overbeck and Helen Bershadskaya Borland JBuilder R&D Engineers November 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?