detroit 0.3.0 → 0.4.0

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA1:
+  metadata.gz: c01bd1c2e302f1b33ce1ba7b8bb1dca2642bb511
+  data.tar.gz: 5a228a2c40736081f686157d33e189b4c74e15a5
+SHA512:
+  metadata.gz: 660dc433b88953988335c2bee9f7d3ac141b1c139b2e63ac43fc0842ad3d8adc3b7cc6e097cb2217c8504a370176815c52487c216d324fb3fc46d34bd9d57d27
+  data.tar.gz: 832de78b8b278321c31196f13dc0540c4ed26c83360c47d92c84add56b6122074999041b17d6718d8a99c117a7e02658bd64b7ac414a712e3560ac0f349ae6e7

data/.index

@@ -0,0 +1,59 @@
+---
+revision: 2013
+type: ruby
+sources:
+- var
+authors:
+- name: Trans
+  email: transfire@gmail.com
+organizations: []
+requirements:
+- name: facets
+- name: indexer
+- groups:
+  - test
+  development: true
+  name: qed
+- groups:
+  - build
+  development: true
+  name: detroit-yard
+- groups:
+  - build
+  development: true
+  name: detroit-gem
+conflicts: []
+alternatives: []
+resources:
+- type: home
+  uri: http://rubyworks.github.com/detroit
+  label: Homepage
+- type: code
+  uri: http://github.com/rubyworks/detroit
+  label: Source Code
+- type: mail
+  uri: http://groups.google.com/rubyworks-mailinglist
+  label: Mailing List
+repositories:
+- name: upstream
+  scm: git
+  uri: http://github.com/proutils/detroit.git
+categories: []
+copyrights:
+- holder: Rubyworks
+  year: '2007'
+  license: GPL-3.0
+customs: []
+paths:
+  lib:
+  - lib
+name: detroit
+title: Detroit
+summary: Software Production Mangement
+created: '2007-10-10'
+description: Detroit is an advanced lifecycle build system. With Detroit, build tasks
+  are user defined service instances tied to stops along a track. Whenever the detroit
+  console command is run, a track is followed from beginning to designated destination.
+suite: detroit
+version: 0.4.0
+date: '2014-01-13'

data/EXAMPLE.md

@@ -1,58 +1,60 @@
 # Detroit
 
-Detroit's main configuration file is called an *assembly*. Assemblies define the 
-<i>service instances</i> that a project will utilize. 
+Detroit's main configuration file is called *toolchain*. Toolchains define
+the  specific *tool instances* that a project will utilize. Toolchains can
+be written in a few different formats thanks to the flexibility of Ruby. All
+formats are equivalent. Which format you use is strictly a regard of your
+personal preference.
 
-Assemblies can be written in a few different formats thanks to the flexibility
-of Ruby. All formats are equivalent. Which format you use is strictly a regard
-of your personal preference.
+## Ruby-based Toolchain Scripts
 
-## Ruby-based Detroit
+### Tool Method Notation
 
-### Service Method Notation
-
-Traditionally a Ruby-based assembly file is dominated by calls to the `service`
-method with an optional service instance name and a setter block.
+Traditionally a Ruby-based toolchain script is dominated by calls to the `tool`
+method with an optional instance name and a setter block.
 
 ```ruby
-  service :myself do |s|
-    s.service = :Announce
-    s.mailto  = "transfire@gmail.com"
-    s.active  = true
+  tool :myself do |s|
+    s.class  = :Announce
+    s.mailto = "transfire@gmail.com"
+    s.active = true
   end
 
-  service :rdoc do |r|
+  tool :rdoc do |r|
     r.include = [ 'lib', '[A-Z]*' ]
-    r.exclude = [ 'Schedule' ]
+    r.exclude = [ 'Gemfile' ]
   end
 ```
 
-If no `service` setting is given, it is assumed to be same as the service instance name.
-In the above example `rdoc` is taken to be both the service desired and the name of
-this particular instance.
+In the first example the tool is given an arbitrary *tool name* and the
+*tool type* is given via the `class` setting. (This setting can also be
+called just `tool`, they are synonymous, but `class` reads better when used 
+with the tool method.) If the tool type is not specified, it is assumed to
+be same as the tool instance name. In the above example `rdoc` is taken to
+be both the type of tool and the name of the particular instance.
 
-A few years ago, Sinatra came along and popularized the use of the `#set` method.
-A simple addition to Detroit's assembly file parser now allows for the slightly
-cleaner notation:
+A few years ago, Sinatra came along and popularized the use of the `#set`
+method. A simple addition to Detroit's toolchain evaluator allows for this
+arguably cleaner notation:
 
 ```ruby
-  service :myself do
-    set :service, :Announce
+  tool :myself do
+    set :tooltype, :Announce
     set :mailto, "transfire@gmail.com"
     set :priority, -1
     set :active, true
   end
 
-  service :rdoc do
+  tool :rdoc do
     set :include, [ 'lib', '[A-Z]*' ]
-    set :exclude, [ 'Schedule' ]
+    set :exclude, [ 'Gemfile' ]
   end
 ```
 
 The `#set` method also allows for nested set blocks to define hash values.
 
 ```ruby
-  service :rubyforge do
+  tool :rubyforge do
     set :sitemap do
       set :site, name
     end
@@ -61,23 +63,23 @@ The `#set` method also allows for nested set blocks to define hash values.
 ```
 
 The setting `active` defaults to `true` if not given, so is not strictly
-needed in the above examples, but it is convenient to have in case you
-ever need to deactivate a service temporarily --more convenient than
-remarking out a whole section. 
+needed in the above examples, but it is convenient to have if a tool ever
+needs to be deactivate temporarily --more convenient than remarking out a
+whole tool entry. 
 
-Almost all options have standard defaults so it is often possible for a service
-definition to be written as simply as:
+Almost all options have standard defaults so it is sometimes possible for
+a tool entry to be written as simply as:
 
 ```ruby
-  service :rdoc
+  tool :rdoc
 ```
 
-### Service Name Notation
+### Tool Name Notation
 
-Thanks to some straight-forward meta-programming, a Ruby-based assembly file can
-be written in a more concise notation by using the name of the service class as a
-method. This can be followed by a settings block, as with the above examples,
-or passed a <i>settings hash</i>. In which case an assembly file can look like this:
+Thanks to some straight-forward meta-programming, a Ruby-based toolchain can
+also be written in a more concise notation by using the name of the tool's class
+as a method. This can be followed by a settings block, as with the above examples,
+or passed a *settings hash*. In which case an toolchain script can look like:
 
 ```ruby
   Announce   :mailto   => "ruby-talk@ruby-lang.org",
@@ -88,8 +90,7 @@ or passed a <i>settings hash</i>. In which case an assembly file can look like t
              :priority => -1
              :active   => true
 
-  Gem        :types    => ['gem'],
-             :spec     => false,
+  Gem        :spec     => false,
              :active   => true
 
   DNote      :priority => -1,
@@ -99,53 +100,50 @@ or passed a <i>settings hash</i>. In which case an assembly file can look like t
              :active   => true
 
   RDoc       :include  => [ 'lib', '[A-Z]*' ],
-             :exclude  => [ 'Schedule' ]
+             :exclude  => [ 'Gemfile' ]
 
   Testrb     :active   => true
 
   Rubyforge  :sitemap  => {
                :site => name
-             }
+             },
              :active   => false
 ```
 
-This format is convenient in that it reduced the amount of extraneous syntax
-need to define service instances. With Ruby 1.9 it can be even more conisce
+This format is convenient in that it reduces the amount of extraneous syntax
+needed to define tool instances. With Ruby 1.9+ it can be even more conisce
 using the new Hash syntax.
 
 ```ruby
   Announce :myself,
-    mailto:   "transfire@gmail.com",
-    priority: -1
-    active:   true
+    mailto: "transfire@gmail.com",
+    priority: -1,
+    active: true
 ```
 
-But you might want to hold off on that a couple of years until Ruby 1.8 is pretty
-much shot and buried ;)
 
-## YAML-based Assembly Files
+## YAML-based Toolchain Scripts
 
 We have saved the most concise notation for last. The YAML format is
-essentially the same as the traditional Ruby format except that
-the main key provides the service instance name and the service is a
-setting which defaults to the name. Also, notice the start document indicator
-(<code>---</code>). The indicator is NECESSARY for the Detroit to be
-recognized as YAML, rather than Ruby.
+essentially the same as the traditional Ruby format except that the
+main key provides the tool instance name and the type is a setting
+which defaults to the name. Also, notice the start document indicator
+(`---`). This indicator MUST BE USED for the file to be recognized
+as YAML, rather than Ruby.
 
 ```yaml
   ---
 
   announce:
-    mailto: "transfire@gmail.com"
+    mailto: transfire@gmail.com
     active: true
 
   myself:
-    service: Announce
-    mailto:  "transfire@gmail.com"
-    active:  true
+    tool:   Announce
+    mailto: transfire@gmail.com
+    active: true
 
   gem:
-    types:    ['gem']
     autospec: false
     active:   true
 
@@ -154,8 +152,8 @@ recognized as YAML, rather than Ruby.
     active:   true
 
   rdoc:
-    include: [ lib, '[A-Z]*' ]
-    exclude: [ Schedule ]
+    include: [ "lib", "[A-Z]*" ]
+    exclude: [ "Gemfile" ]
 
   ri:
     exclude: []
@@ -169,12 +167,16 @@ recognized as YAML, rather than Ruby.
     active: true
 
   rubyforge:
-    service: forge
+    type: forge
     sitemap:
       site: <% name %>
     active: false
+```
+
+Notice we used the the alternate setting `tool` instead of `class` for the 
+`myself` announce tool instance. The effect is exactly the same.
 
-As we can see in the last entry, the YAML format also supports ERB and provides
+Also notice the last entry, the YAML format supports ERB and provides
 access to project metadata via the ERB's binding.
 
 With the Ruby format it is easy enough to load external library using

data/{HISTORY.rdoc → HISTORY.md}

@@ -1,6 +1,33 @@
-= RELEASE HISTORY
+# RELEASE HISTORY
 
-== 0.3.0 / 2012-04-02
+## 0.4.0 / 2014-01-14
+
+The big change of this release is the swapping of terminology of
+`assembly` and `toolchain`. What was once called an "Assembly" is
+now called a "Toolchain" and vice-versa. This, when thought through,
+makes much more sense. But it has a big effect on every project that
+uses Detroit in that a project's `Assembly` file must be renamed 
+to `Toolchain`.
+
+This release also modifies the interface change of the previous release
+slightly, such that the `assemble` methods do not have to be manually
+defined, although it is still recommended. By default the base class
+definition will look to see if a method of the same name as a station
+is defined in the tool class. Note this differs from using `respond_to?`
+which will return `true` if the method was defined in any part of the
+class hierarchy. Instead the method must be defined directly in the class.
+This helps ensure there are no accidental name clashes between support
+code and assembly stations (which was the purpose of the original
+`station_` that was deprecated in the last release). 
+
+Changes:
+
+* Rename `assembly` to `toolchain` and vice-versa.
+* No longer *requires* custom `assemble` methods for each tool.
+* Improved code organization and plenty of bug fixes.
+
+
+## 0.3.0 / 2012-04-02
 
 This significant release changes the interface for tools to tap
 into the assembly line. Where as before specially named methods
@@ -13,10 +40,10 @@ Changes:
 
 * Simplify the assembly interface for tools.
 * Tool classes ending in Base are abstract base class.
-* Add #on as alias from #track.
+* Add #on as alias for #track.
 
 
-== 0.2.0 / 2011-10-19
+## 0.2.0 / 2011-10-19
 
 The big news here is that Detroit configuration files are now
 called _assembly_ files, and no longer _schedule_ files. The
@@ -36,7 +63,7 @@ Changes:
 * Fix --config output.
 
 
-== 0.1.0 / 2011-06-29
+## 0.1.0 / 2011-06-29
 
 Detroit is a lifecycle build system for Ruby. Detroit was originally
 called Syckle, and was developed and used in house for Rubyworks projects

data/README.md

@@ -0,0 +1,142 @@
+# Detroit
+
+[Website](http://rubyworks.github.io/detroit) /
+[Report Issue](http://github.com/rubyworks/detroit/issues) /
+[Development](http://github.com/rubyworks/detroit)
+
+[![Build Status](http://travis-ci.org/rubyworks/detroit.png)](http://travis-ci.org/rubyworks/detroit) 
+[![Gem Version](https://badge.fury.io/rb/detroit.png)](http://badge.fury.io/rb/detroit)    
+[![Flattr Me](http://api.flattr.com/button/flattr-badge-large.png)](http://flattr.com/thing/324911/Rubyworks-Ruby-Development-Fund)
+
+
+## About
+
+Detroit is a software production management aid, aka a *build tool*.
+Detroit utilizes a life-cycle methodology to help developers
+prepare and release software in a clear, repeatable, and linear fashion.
+While written in, and therefore well-suited to Ruby development, Detroit
+can be used for any language and production requirements.
+
+
+## How It Works
+
+Detroit defines development processions call *assemblies* which consist of
+a set of production *lines* each with a series of named *stations*, or *stops*.
+Developers attach work elements to stations by creating configuring tool
+instances in a project's Toolchain file. Toolchain files are written
+in either YAML or a Ruby DSL.
+
+For example, a RubyForge tool can be configured:
+
+    rubyforge:
+      tool: Rubyforge
+      sitemap:
+        site: <%= name %>
+      active: true
+
+As this example demonstrates, tool configurations can draw on project
+metadata via ERB embedded tags. Detroit gathers this information using
+[.index](http://dotruby.github.com/indexer) file, but the data source
+can be customized to meet the needs of different projects. (For instance,
+for Ruby projects, if no .index file is found, Detroit will attempt get the
+information from a .gemspec file.)
+
+With tool configuration and metadata in place, using Detroit is simply
+a matter of passing a stop to the `detroit` command. 
+
+    $ detroit document
+
+The use of lines may seem constrictive to users of tools like Rake, but
+there is a benefit to this approach. It helps ensure a project is 
+always up-to-date and in-sync --that no necessary steps are missed.
+Detroit standard asembly has two lines. The most significant of which is
+main line which entails a route with ordred stops:
+
+    prepare     # prepare services and ensure requirements
+    generate    # code generation
+    compile     # compile source code
+    test        # run tests and/or specifications
+    analyze     # run code analysis
+    document    # generate documentation
+    package     # create packages
+    verify      # post package verification (eg. integration tests)
+    install     # install package locally
+    publish     # publish website/documentation
+    release     # release packages
+    deploy      # deply system to servers
+    promote     # tell the world about you awesome work
+
+The second line is maintainence line which consits of three stops:
+
+    reset       # mark build files as out-of-date
+    clean       # remove minor build files
+    purge       # remove all build files
+
+Where reset marks generated files out-of-date, clean removes temporary
+products and purge removes all generated prodcuts.
+
+To refine control over the build process, tool instances can be grouped into
+different *tracks*. For example, a Github gh-pages tool might be configured
+to be on a `site` track, so publishing a project's website only occurs if
+the `site` track is specified along with `publish` stop.
+
+    $ detroit site:publish
+
+Please see http://rubyworks.github.com/detroit for more details on how to
+use Detroit, including the creation of tracks, stops and tool plugins.
+Also try the `--help` option to see the detroit command's help
+information.
+
+
+## Install
+
+Detroit can, of course, be installed via RubyGems:
+
+    $ gem install detroit
+
+Once installed, developers need to also install the specific plugins
+for the tools to be used. For example,
+
+    $ gem install detroit-github
+    $ gem install detroit-minitest
+    $ gem install detroit-yard
+
+If using Bundler, just add these to the project's Gemfile instead.
+
+
+## Issues
+
+All in all, Detroit works well. There are some rough edges with regards
+to the plugins, so from time to time you might run into an odd error.
+Ususally it just means a tool confirguraiton needs adjustment.
+
+Please note, Windows support has not been considered at all. While we see
+no specific reason it should not work, there may well be issues we have not
+considered since we do not use Windows. If you are Windows user and give
+Detroit a try please let us know of any issues you encounter.
+
+
+## History
+
+Detroit is actaully a fork of Reap v10, and was called Syckle for a number
+of years as it matured. It represents many years of design considerations
+(and reconsiderations) that evolved Reap from its simple Rake extension
+origins (which pre-date Hoe) to the life-cycle system it is today.
+
+
+## Legal
+
+Copyright (c) 2007 Rubyworks (GPL-3.0 License)
+
+This program is free software: you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation, either version 3 of the License, or
+(at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+See LICENSE.txt for details.
+