FAQ
1. If you're using Java 1.3, our
installer currently does not support Java 1.3. You may use the
-vm command line argument to specify a differenct JVM to be used by the installer.
Example: Product_v1.0.1_win32_x86.exe -vm "C:\Program Files\java\jdk1.5.0_05\jre\bin\java.exe"
2. In
cases where the installer can not find your TEMP or TMP environment
variable, you can also specify a different Temp directory by adding the
-tmp option. You have to create the c:\mytemp folder first before running the installer.
Example: Product_v1.0.1_win32_x86.exe -tmp c:\Temp
3. In some cases where the splash screen won't come up, run the installer with the
-nosplash option.
Example: Product_v1.0.1_win32_x86.exe -nosplash
4. If none of the above help, run the installer with
-out option to generate a log file.
This will run the installer in verbose mode and
redirect
output to the file
installer.log
in the directory where the installer is located.
Examine the log file to determine the cause or send the log file to support and we'll take a look.
Example: Product_v1.0.1_win32_x86.exe -out installer.log
--verbose Officially,
CodePro supports WebSphere Application Developer 5.1, Rational Application
Developer 6.0 & 7.0 and the Eclipse
2.1, 3.0, 3.1, 3.2 & 3.3 code streams. See
the
System Requirements
page for full details. EclipsePro only supports Eclipse and not
Application Developer. CodePro AnalytiX Rational Edition only supports
Rational Application Developer and Software Architect.
Unofficially,
CodePro/EclipsePro supports the emerging Eclipse open source code stream in "beta
test" mode on the most recent "
stable"
build. As new stable builds are released, we will try to get the product updated within a
few days. We do not plan to support any of the "
integration"
or "
nightly"
builds.
CodePro runs on the Microsoft Windows family of operating systems as well as
Linux and Macintosh OSX. Other operating systems will be considered as IBM adds support for them to Eclipse.
See the
System Requirements page for full details.
Note that the
VCE Bridge and
BeanInfo Bridge features only work under Windows
as they require VA Java with VA Assist loaded (which is only available under Windows).
Begin by specifying the
starting amount of memory (-vmargs -Xms###m)
in your Application Developer/Eclipse startup command line (e.g., the
target field within a Windows shortcut). If this is
not specified,
Eclipse's starting amount of memory is quite small (only 40 MB). You
should also specify the
maximum amount of memory that Eclipse can
use (-vmargs -Xmx###m) and the maximum amount of perm space available (-vmargs -XX:MaxPermSize=###m).
We typically recommend something like this:
- -vmargs -XX:MaxPermSize=128m -Xms256m
-Xmx512m
Yes. CodePro has a very large number of
features, some of which may be turned off to improve overall system
performance.
- History views - CodePro tracks every Java file you access in
its History view and every
modified type of method in its Modified
Types and Modified
Members views. The history data is persisted a across sessions and
reconstituted on startup. If you don't need this feature, you can save
a small amount of startup time and file access/modification time by
unchecking the Track modified elements and Track history
options on the CodePro
| History preference page.
- Task Scheduler - If you do not have a need to run scheduled
tasks at startup, you can uncheck the CodePro - Core UI option
on the Eclipse Workbench | Startup preference page.
- CodePro Splash Screen - You can disable this in two ways by
either unchecking the CodePro - Splash option on the Eclipse Workbench
| Startup preference page or by unchecking the Show splash
screen at startup option on the CodePro
| Startup preference page.
- CodePro Menu - If you don't need quick access to CodePro
features available from this menu, you can disable it by unchecking
the Show CodePro menu option on the CodePro
| Startup preference page.
- Dynamic Code Auditing - When dynamic code auditing is
enabled, any Java file that is open that matches your dynamic audit
criteria will be automatically audited when it is opened. If you have
files open at shutdown, they will be automatically audited at startup.
To disable dynamic code auditing, uncheck the Dynamically audit code
option on the CodePro
| Audit | Dynamic preference page.
- Browser Colors - If you are using any of the CodePro enhanced
perspectives (e.g., Java+, Java Browsing+ or Resources+), CodePro
provides options to color highlight resources based on their error
status, repository change status or their age. You can turn off any or
all of these options via the CodePro
| Browsers preference page.
Eclipse 3.x and other IDEs based upon Eclipse
3.x may not immediately recognize new tools if they are not installed using
the Eclipse Install and Update Manager. This occurs because Eclipse 3.x
caches plug-in information for a faster startup at the cost of not
recognizing changes to the installed plugins. To workaround this problem,
include the "-clean" option on the command line used to startup Eclipse. The
"-clean" option causes Eclipse to reparse and recache the plug-in
information, picking up any newly installed or revised features. Once the
plug-in information has been recached and CodePro appears as expected, you
can remove the "-clean" option.
An alternative (and often more
effective choice) to the
"-clean" option is to clean the Eclipse "configuration" directory as
follows. If you are installing into Eclipse 3.0, you should also delete your <Eclipse>/configuration
directory before re-starting Eclipse (it is recreated at startup). This is to
avoid a common Eclipse 3.x plugin cache bug. The Full Installer can do this
for you automatically. If you are installing into Eclipse 3.1, 3.2 or 3.3, delete
everything in the "configuration" directory except the
config.ini file and the org.eclipse.update/platform.xml file
(Eclipse 3.2 and above). You should also keep your org.eclipse.update/bookmarks.xml
file (Eclipse 3.1 and above) in order to preserve your update site
bookmarks.
Note that this problem is likely due to Eclipse
Bug #68097. From the Eclipse 3.0 readme file:
Manually installing features and plug-ins on a FAT file system
(Windows only)
When features and plug-ins are manually installed on top of an
Eclipse-based product install located on a FAT file system that has
already been run at least once, the product must be explicitly restarted
with the system property osgi.checkConfiguration set to true. This
property can be set in the eclipse/configuration/config.ini file, or
passed to the eclipse command line via the -vmargs option. For example,
restart with the following command: eclipse.exe -vmargs -Dosgi.checkConfiguration=true.
Then, open Help > Software Updates > Manage Configuration dialog and
toggle on the "Show disabled features" button its toolbar.
Select the newly "installed" feature and press on the
"Enable feature" action on the right pane (or select the action
from the feature's context menu). (bugs 52525,
66120, 67461).
Make sure
you don't have an older version of CodePro installed. If you have a linked
installation, check the links files to make sure they are pointing to the
correct version. If you copied the plugins into the eclipse plugins
directory, please install on a fresh copy of Eclipse. Lastly, try clearing
your eclipse configuration directory by deleting everything except for the
config.ini file.
Yes. ClearCase
uses a pessimistic "check-in/check-out" model. Many operations in Eclipse will
fail unless a type is properly checked out before editing (refactoring, for example). The
same is true for specific CodePro features such as the
VCE Bridge and
BeanInfo
Bridge. In order for the "Edit GUI" and "Edit BeanInfo" commands
to work, make sure that the class that you plan to edit has been properly checked out from
ClearCase.
VA Java does not
recreate the VCE layout information from the source of the class. Rather, it stores that
meta data within the repository. VA Java does provide a source code generation option for
generating that meta data into a special
getBuilderData() method. That
method must be present in any exported class for it to be properly edited using the VA
Java VCE and, consequently, the
VCE Bridge. Rather
than forcing you to go back an regenerate all of the source for your GUI classes,
VA Assist provides
a convenient "
Generate missing meta data methods on export" option that will
cause those missing methods to be generated any time a class is exported either to a
directory
or directly to
Application Developer/Eclipse.
Yes. Any custom parts or nested components
need to be present within VA Java. All you need to do is load the VA Java
project containing the referenced components before invoking the
VCE Bridge.
One of the basic assumptions of the
VCE Bridge
is that you are editing GUI classes originally created in VA Java so you
would have those pieces available already in VA Java. If you load your VA
Java projects into VA Java, that should solve any dependency problems that
you might have.
The VA Java GUI builder only knows about types within its environment.
If you want to use classes that you have created in Eclipse, you will need
to import them into the VA Java environment you want to use. The direct
import from Eclipse option that has been added to the
Import
Wizard by
VA Assist
should make that easy. If you plan to do this frequently, you might want
to set up an
Eclipse
Import set on the VA Java side and use the
Task
Scheduler to have it run automatically at VA Java startup. That way,
whenever you invoke the
VCE Bridge
it will automatically import your new/changed beans and make them
available for use.
Here are some questions to ask yourself and
some suggestions:
- Do you have VA Assist installed into VA Java. What version of VA
Assist are you using?
- Is CodePro configured to talk to your VA Java installation?
./preferences/preferences_vaassist.html - Is VA Assist in VAJ configured to know about your Eclipse
installation?
http://www.instantiations.com/assist/docs/options_eclipse.htm
Sending us a screen shot of both of the above screens in your
environment might help us identify the problem. Are any exceptions
recorded either into the VA Java "ide\program\va-debug.log"
file, the Eclipse "<workspace>\.metadata\.log" file or the
"<workspace>\.metadata\.plugins\com.instantiations.assist.eclipse.core\ws-debug.log"
file? If so, please send us those files. If none are recorded, you can try
turning on the "log communications" options in both products
which will cause communication status messages to be recorded to the log
files which should help us analyze the problem.