Known Issues with the Eclipse plug-ins

This article provides information about several known issues with the WebSphere® sMash plug-ins for Eclipse.

Groovy support

Groovy feature version 1.5.7 is invalid

Users must not install the Groovy feature version 1.5.7 because it is incompatible with the WebSphere sMash runtime. To obtain the valid version of this feature, install it from the Groovy entry under the WebSphere sMash update site. For more information, please see this forum post on projectzero.org.

Eclipse update site adds strange location

Users who install the Groovy feature from the WebSphere sMash update site will see a new update site added to their update manager. This update site points to codehaus.org which is the originator of the Groovy feature. However, this update site has a name which refers to a non-existent filesystem path.

This problem is a bug with the codehaus.org update site. Users should avoid using this update site.

Please see Bug 7647 for more information.

Apply step filters for easier Groovy debugging

When you perform a step operation (step into, step over, step out) from a Groovy script, you may be taken to an implementation class of the Groovy engine instead of to the function that was called by the script. This behavior makes debugging very difficult. Fortunately Eclipse provides step filters that allow step operations to ignore certain code artifacts.

  1. Click Window > Preferences....
  2. Select Java > Debug > Step Filtering.
  3. Check Use Step Filters.
  4. Add the following entries to the list:
    • groovy.*
    • org.codehaus.groovy.*
    • zero.core.groovysupport.*
  5. Click Apply then OK.

The next time you debug a Groovy script, step operations will ignore classes that live under the filtered packages. However, you will still see entries for these classes on the stack trace.

Miscellaneous issues

Eclipse creates class files when compilation errors exist

The Eclipse Java builder can create class files in cases where compilation errors are known to exist. These classes will allow the application to run despite the errors. The WebSphere sMash Command-Line Interface uses the default Java compiler (javac) which does not do this. As a result, you may see different error information depending on which tool performed the last Java compile. The steps below describe how to reproduce this effect.

  1. Create a WebSphere sMash application in Eclipse.
  2. Write some Java code that contains a compilation error. Eclipse should build class files for the code. You can verify this by looking in the classes directory.
  3. Import the application into the App Builder using "Browse Applications".
  4. Create a Groovy script under /public that invokes the broken code.
  5. Start the application and open a browser to the Groovy script.
  6. In the browser you will see a long Java stack trace containing the broken code.
  7. Now open the Java code in the App Builder and cause it to be compiled there by adding a space.
  8. After the build runs, verify that the classes directory is empty.
  9. Stop and restart the application.
  10. Browse the Groovy script again. This time you will see a Script Compile Error in the Groovy script. The Java code was not entered at all.

No code completion in a PHP application

This problem only affects users of the WebSphere sMash PHP plug-in. Users may encounter a situation where code completion for WebSphere sMash API calls is not available.

The workaround is to close any files from the project and then close the project itself. Then reopen the project, and code completion will be enabled.

Please see Bug 5300 for more information.

Eclipse freezes when building workspace

This problem can occur while importing multiple WebSphere sMash applications as existing projects.

The workaround is to disable the "Resolve Automatically" preference before importing large project sets into the workspace. Further, removing the Groovy nature and Groovy builders from WebSphere sMash projects will improve performance.

Please see Bug 6985 for more information.

Eclipse file encoding defaults

It is recommended that all source text files in a WebSphere sMash project be encoded as UTF-8, so that all applications can easily support any language. The sMash CLI will expect all input files to commands, such as compile and runsql are formatted as UTF-8. Refer to the Eclipse documentation for information on how to set the encoding of text files.

Version 2.0.30111