The plugin model is based on Spring. Each plugin jar is required to contain the file META-INF/spring/spring-shell-plugin.xml. These files will be loaded to bootstrap a Spring ApplicationContext when the shell is started. The essential boostrapping code that looks for your contributions looks like this:

new ClassPathXmlApplicationContext("classpath*:/META-INF/spring/spring-shell-plugin.xml");

In the spring-shell-plugin.xml file you should define the command classes and any other collaborating objects that support the command's actions. The plugin model is depicted in the following diagram

Note that the current plugin model loads all plugins under the same class loader. An open JIRA issue suggests providing a classloader per plugin to provide isolation.

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans 
       http://www.springframework.org/schema/beans/spring-beans.xsd
       http://www.springframework.org/schema/context 
       http://www.springframework.org/schema/context/spring-context-3.1.xsd">

  <context:component-scan 
           base-package="org.springframework.shell.samples.helloworld.commands" />

</beans>

@Component
public class HelloWorldCommands implements CommandMarker {

  // use any Spring annotations for Dependency Injection or other Spring 
  // interfaces as required.

  // methods with @Cli annotations go here

}

There are a few built in commands. Here is a listing of their class name and functionality

There are two commands in provided by the AbstractShell class related to useage of block comments

There are a few extension points that allow you to customize the shell. The extension points are the interfaces

There is a default implementation for these interfaces but you should create your own implementations for your own shell application. All of these interfaces extend from NamedProvider. Use Spring's @Order annotation to set the priority of the provider. This allows your provider implementations to take precedence over any other implementations that maybe present on the classpath from other plugins.

To make cool "ASCII art" banners the website http://patorjk.com/software/taag is quite neat!

As this is a standard Spring application you can use Spring's ApplicationContext event infrastructure to communicate across plugins.

It has shown to be useful to provide a simple form of interception around the invocation of a command method. This enables the command class to check for updates to state, such as configuration information modified by other plugins, before the command method is executed. The interface ExecutionProcessor should be implemented instead of CommandMarker to access this functionality. The ExecutionProcessor interface is shown below

public interface ExecutionProcessor extends CommandMarker {

 /**
  * Method called before invoking the target command (described by {@link ParseResult}).
  * Additionally, for advanced cases, the parse result itself effectively changing the 
  * invocation calling site.
  * 
  * @param invocationContext target command context
  * @return the invocation target 
  */
 ParseResult beforeInvocation(ParseResult invocationContext);

 /**
  * Method called after successfully invoking the target command (described by 
  * {@link ParseResult}).
  * 
  * @param invocationContext target command context
  * @param result the invocation result
  */
 void afterReturningInvocation(ParseResult invocationContext, Object result);

 /**
  * Method called after invoking the target command (described by {@link ParseResult}) 
  * had thrown an exception .
  * 
  * @param invocationContext target command context
  * @param thrown the thrown object
  */
 void afterThrowingInvocation(ParseResult invocationContext, Throwable thrown);

}

There are a few command line options that can be specified when starting the shell. They are

Scripts can be executed either by passing in the --cmdfile argument at startup or by executing the script command inside the shell. When using scripts it helps to add comments and this can be done using block comments that start and end with /* and */ or an inline one line comment using the // or ; characters.