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 different 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.
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:
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.
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.
The CodePro Server Ant tasks for audit, metrics, and dashboard creation will produce debugging output if you include the additional attribute
debug="true"
This attribute will cause additional information to be written to the Ant output and will cause several large directories of information to be left on disk for debugging purposes. In particular, the configuration and workspace directories used by Eclipse will not be deleted. Unless otherwise specified, those directories are located in the temporary directory, inside a subdirectory named "instantiations", in a directory whose name is the name of the task for which debugging was enabled and a timestamp of when the directory was created. For example:
C:\Temp\instantiations\audit-20090802161035
Each such directory will contain, in addition to the configuration and workspace directories, the input and output files for Server. The Ant tasks create an input file (named "audit.xml" in the above example) to communicate with Server and Server produces an output file to communicate results back to the Ant tasks (named "audit.properties" in the above example).
For debugging purposes, both of these files, the content of the Ant output, and the Eclipse log file (located as usual in "workspace/.metadata/.log") are all useful to us.