1. How to Make Your Java Projects Coexist in JBuilder and Eclipse
Charles Overbeck and Helen Bershadskaya
Borland JBuilder R&D Engineers
November 9, 2005

2. 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

3. 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

4. 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

5. 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?

6. 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

7. 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.

8. 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.

9. Simple Project Coexistence Example
Demo

10. 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

11. 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…

12. 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

13. 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

14. 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.

15. 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.

16. 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:
/** */
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.

17. 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 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.

18. 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

19. 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.

20. J2EE Projects -- JBuilder
Illustration of J2EE project code in JBuilder and Eclipse

21. 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

22. Writing Eclipse Plugins
Eclipse is clearly at an advantage here

23. 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

24. 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

25. Sneak Peek
Preview of Peloton importing from a JBuilder project

26. 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

27. Q&A
Questions?