Transcript How to Make your Java Projects Coexist in JBuilder and Eclipse

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?