Using Eclipse with WebSphere sMash and App Builder

Changes to Eclipse preferences

By default, the WebSphere sMash Eclipse plug-ins (both Java™/Groovy and PHP) are configured for the latest builds of WebSphere sMash. If you want to use the WebSphere sMash Eclipse plug-ins with a released version of WebSphere sMash, then you must change the preferences, as noted in the following sections.

Synchronizing Eclipse with your CLI repository

These instructions apply if you plan to use the CLI in conjunction with applications you create and/or develop in Eclipse. Several of the WebSphere sMash examples require you to use a CLI before you run them. These examples can be downloaded into Eclipse as explained in the Installing and configuring: Eclipse for Java and Groovy article.

By default, Eclipse uses a local repository that is created under your user home directory. This repository stores code artifacts that are used during dependency resolution. By contrast, the CLI uses a local repository that is a subdirectory of the CLI itself. When developing applications that are touched by Eclipse and the CLI, it is a good idea to use the same local repository for both.

1. Click Window > Preferences....
2. Select the WebSphere sMash category.
3. Under the Local Repository Home heading, enter the full path to a module group directory from your CLI. If your CLI is installed at /home/zero then any module groups that have been created will have a subdirectory under /home/zero/zero-repository. For example, the stable WebSphere sMash module group will have the following path: /home/zero/zero-repository/stable.

Configure the remote repository chain

These instructions apply if you plan to develop code that depends on a stable WebSphere sMash module group. By default, the Eclipse plug-in is configured to use the repository for the latest WebSphere sMash build.

1. Click Window > Preferences....
2. Select the WebSphere sMash category.
3. Under the Configure the Remote repository chain heading, select the item that begins with zero and click Remove.
4. Click New....
5. In the dialog that opens, select WebSphere sMash Repository and insert one of the following URLs into the text field:
   • http://www.projectzero.org/sMash/1.0.x/repo/base/
   • http://www.projectzero.org/sMash/1.0.x/repo/rte/
   • http://www.projectzero.org/sMash/1.0.x/repo/samples/
6. Repeat the previous two steps as many times as necessary.

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.

Known issues

There are several known issues that users have encountered when trying to use Eclipse with the CLI or App Builder.

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.

Eclipse does not recognize module groups

The Eclipse plug-ins are based on an older version of the CLI that does not support module groups. What this means is that when you configure your Eclipse repository using the instructions above titled Point Eclipse to your CLI repository, you will be using a single module group for all of your applications. If you need to use an additional module group, you will have to use the CLI to switch to the new module group and then update your Eclipse repository setting appropriately. You will also need to use the CLI to perform any other module group operations like creation and deletion. For more information, run the following CLI task: zero modulegroup help