anchor.diff:  
   [source]
   ....
  -$STORM_HOME/bin/storm jar target/storm-solr-1.0.jar com.lucidworks.storm.StreamingApp \
  +$STORM_HOME/bin/storm jar target/${jarfilename} com.lucidworks.storm.StreamingApp \
      example.twitter.TwitterToSolrTopology -env staging -config MyConfig.groovy
   ....
   
  
positive.code: :linkattrs:
  :source-highlighter: pygments
  :pygments-style: tango
  
  Tools for building Storm topologies for indexing data into SolrCloud.
  
  
negative.code: 
  To begin, let’s understand how to run a topology in Storm. Effectively, there are two basic modes of running a Storm topology: local and cluster mode. Local mode is great for testing your topology locally before pushing it out to a remote Storm cluster, such as staging or production. For starters, you need to compile and package your code and all of its dependencies into a single JAR with an main class that runs your topology.
  
  For this project, the Maven Shade plugin is used to create a unified JAR with dependencies. The benefit of the Shade plugin is that it can relocate classes into different packages at the byte-code level to avoid dependency conflicts. This comes in quite handy if your application depends on 3rd party libraries that conflict with classes on the Storm classpath. You can look at the project pom.xml file for specific details about I use the Shade plugin. For now, let it suffice to say that the project makes it very easy to build a Storm JAR for your application. Once you have a unified JAR ({jarfilename}), you’re ready to run your topology in Storm.
  
  To run locally, you need to have some code that starts up a local cluster in the JVM, submits your topology, and then waits for some configurable amount of time before shutting it all back down, as shown in the following code:
  
  