tree: f42b3dff5b4adec5f3237208f76edd5901f1bb55 [path history] [tgz]
  1. _includes/
  2. _layouts/
  3. _plugins/
  4. _sass/
  5. assets/
  6. css/
  7. images/
  8. _config.yml
  9. Acking-framework-implementation.md
  10. Clojure-DSL.md
  11. Command-line-client.md
  12. Common-patterns.md
  13. Concepts.md
  14. Configuration.md
  15. Contributing-to-Storm.md
  16. Creating-a-new-Storm-project.md
  17. Daemon-Fault-Tolerance.md
  18. Defining-a-non-jvm-language-dsl-for-storm.md
  19. distcache-blobstore.md
  20. Distributed-RPC.md
  21. DSLs-and-multilang-adapters.md
  22. dynamic-log-level-settings.md
  23. dynamic-worker-profiling.md
  24. Eventlogging.md
  25. FAQ.md
  26. Fault-tolerance.md
  27. favicon.ico
  28. flux.md
  29. Guaranteeing-message-processing.md
  30. Hooks.md
  31. Implementation-docs.md
  32. index.md
  33. Installing-native-dependencies.md
  34. Kestrel-and-Storm.md
  35. Lifecycle-of-a-topology.md
  36. Local-mode.md
  37. Logs.md
  38. Maven.md
  39. Message-passing-implementation.md
  40. Metrics.md
  41. Multilang-protocol.md
  42. nimbus-ha-design.md
  43. Pacemaker.md
  44. Powered-By.md
  45. Project-ideas.md
  46. Rationale.md
  47. README.md
  48. Resource_Aware_Scheduler_overview.md
  49. Running-topologies-on-a-production-cluster.md
  50. SECURITY.md
  51. Serialization-(prior-to-0.6.0).md
  52. Serialization.md
  53. Serializers.md
  54. Setting-up-a-Storm-cluster.md
  55. Setting-up-a-Storm-project-in-Eclipse.md
  56. Setting-up-development-environment.md
  57. Spout-implementations.md
  58. State-checkpointing.md
  59. storm-cassandra.md
  60. storm-elasticsearch.md
  61. storm-eventhubs.md
  62. storm-hbase.md
  63. storm-hdfs.md
  64. storm-hive.md
  65. storm-jdbc.md
  66. storm-jms-example.md
  67. storm-jms-spring.md
  68. storm-jms.md
  69. storm-kafka-client.md
  70. storm-kafka.md
  71. storm-metrics-profiling-internal-actions.md
  72. storm-mongodb.md
  73. storm-mqtt.md
  74. Storm-multi-language-protocol-(versions-0.7.0-and-below).md
  75. storm-redis.md
  76. Storm-Scheduler.md
  77. storm-solr.md
  78. storm-sql-internal.md
  79. storm-sql.md
  80. STORM-UI-REST-API.md
  81. Structure-of-the-codebase.md
  82. Support-for-non-java-languages.md
  83. Transactional-topologies.md
  84. Trident-API-Overview.md
  85. Trident-RAS-API.md
  86. Trident-spouts.md
  87. Trident-state.md
  88. Trident-tutorial.md
  89. Troubleshooting.md
  90. Tutorial.md
  91. Understanding-the-parallelism-of-a-Storm-topology.md
  92. Using-non-JVM-languages-with-Storm.md
  93. Windowing.md
  94. windows-users-guide.md
docs/README.md

Apache Storm Website and Documentation

This is the source for the Release specific part of the Apache Storm website and documentation. It is statically generated using jekyll.

Generate Javadoc

You have to generate javadoc on project root before generating document site.

mvn javadoc:javadoc -Dnotimestamp=true
mvn javadoc:aggregate -DreportOutputDirectory=./docs/ -DdestDir=javadocs -Dnotimestamp=true

You need to create distribution package with gpg certificate. Please refer here.

Site Generation

First install jekyll (assuming you have ruby installed):

gem install jekyll

Generate the site, and start a server locally:

cd docs
jekyll serve -w

The -w option tells jekyll to watch for changes to files and regenerate the site automatically when any content changes.

Point your browser to http://localhost:4000

By default, jekyll will generate the site in a _site directory.

This will only show the portion of the documentation that is specific to this release.

Adding a new release to the website

In order to add a new relase, you must have committer access to Storm's subversion repository at https://svn.apache.org/repos/asf/storm/site.

Release documentation is placed under the releases directory named after the release version. Most metadata about the release will be generated automatically from the name using a jekyll plugin. Or by plaing them in the _data/releases.yml file.

To create a new release run the following from the main git directory

mvn javadoc:javadoc -Dnotimestamp=true
mvn javadoc:aggregate -DreportOutputDirectory=./docs/ -DdestDir=javadocs -Dnotimestamp=true
mkdir ${path_to_svn}/releases/${release_name}
#Copy everything over, and compare checksums, except for things that are part of the site,
# and are not release specific like the _* directories that are jekyll specific
# assests/ css/ and README.md
rsync -ac --delete --exclude _\* --exclude assets --exclude css --exclude README.md ./docs/ ${path_to_svn}/releases/${release_name}
cd ${path_to_svn}
svn add releases/${release_name}
svn commit

to publish a new release run

cd ${path_to_svn}
jekyll build -d publish/
svn add publish/ #Add any new files
svn commit

How release specific docs work

Release specific documentation is controlled by a jekyll plugin releases.rb

If the plugin is running from the git repo the config storm_release_only is set and teh plugin will treat all of the markdown files as release sepcific file.

If it is running from the subversion repositiory it will look in the releases driectory for release sepcific docs.

http://svn.apache.org/viewvc/storm/site/releases/

Each sub directory named after the release in question. The “current” release is pointed to by a symlink in that directory called current.

The plugin sets three configs for each release page.

  • version - the version number of the release/directory
  • git-tree-base - a link to a directory in github that this version is on
  • git-blob-base - a link to to where on github that this version is on, but should be used when pointing to files.

If storm_release_only is set for the project the version is determined from the maven pom.xml and the branch is the current branch in git. If it is not set the version is determined by the name of the sub-directory and branch is assumed to be a "v#{version}" which corresponds with our naming conventions. For SNAPSHOT releases you will need to override this in _data/releases.yml

The plugin also augments the site.data.releases dataset. Each release in the list includes the following, and each can be set in _data/releases.yml to override what is automatically generated by the plugin.

  • git-tag-or-branch - tag or branch name on github/apache/storm
  • git-tree-base - a link to a directory in github that this version is on
  • git-blob-base - a link to to where on github that this version is on, but should be used when pointing to files.
  • base-name - name of the release files to download, without the .tar.gz
  • has-download - if this is an official release and a download link should be created.

So if you wanted to create a link to a file on github inside the release specific docs you would create a link like

[LICENSE]([DEVELOPER.md]({{page.git-blob-base}}/LICENSE)

If you wanted to create a maven string to tell people what dependency to use you would do something like

<dependency>
  ...
  <version>{{version}}</version>
</dependency>

If you want to refer to a javadoc for the current release use a relative path. It will be in the javadocs subdirectory.

[TopologyBuilder](javadocs/org/apache/storm/topology/TopologyBuilder.html)