Packaging the Code

When packaging the code into jar files for a plug-in, follow these guidelines:

Separate the code into three distinct pieces:
- Code that is only used on the client
- Code that is only used on the server
- Code that is used in both places
Set up the build tools to compile and package these pieces separately to prevent crossover compilation. For example, the framework is packaged into the following jar files:
```
   framework_client.jar
   framework_common.jar
   framework_server.jar
```
Package the command listener classes in the server jar
Package the command descriptor classes in the server jar. This is because they contain references to the method names in the command listeners and this should not be publicly available on the client.
Package the CommandString derived classes in the common jar file. While the framework does not currently take advantage of this on the client, it will be upgraded to do the packaging of parameters and commands for client applications.
Place any classes extending CommandStatus in the common jar file.
Place any specialized classes (such as Example.java) in the common jar file.

The server jar file must contain a manifest file. Each command listener must have an entry in this manifest file that looks like the following:

Name: ExampleCommandListener.class

EAS-Framework-CommandListener: True

If, as is likely, the command listener has a package name that must be prepended to the name in the example above, like this:

Name: com/essbase/eas/examples/server/ExampleCommandListener.class

EAS-Framework-CommandListener: True

Note:

Even though this is a class name, use slashes (“/”) instead of dots (“.”) to separate the package names.