doubleshot 0.2.0-java → 0.3.0-java

Sign up to get free protection for your applications and to get access to all the features.
Files changed (47) hide show
  1. data/Doubleshot +16 -6
  2. data/README-OLD.textile +216 -0
  3. data/README.textile +38 -182
  4. data/lib/doubleshot.rb +100 -39
  5. data/lib/doubleshot/commands/gem.rb +15 -12
  6. data/lib/doubleshot/commands/test.rb +38 -5
  7. data/lib/doubleshot/configuration.rb +2 -2
  8. data/lib/doubleshot/dependencies/dependency.rb +1 -1
  9. data/lib/doubleshot/dependencies/gem_dependency.rb +2 -10
  10. data/lib/doubleshot/dependencies/jar_dependency.rb +12 -2
  11. data/lib/doubleshot/lockfile.rb +9 -6
  12. data/lib/doubleshot/pom.rb +15 -2
  13. data/lib/doubleshot/resolver.rb +1 -0
  14. data/lib/doubleshot/resolver/gem_resolver.rb +45 -0
  15. data/lib/doubleshot/resolver/gem_resolver/artifact.rb +146 -0
  16. data/lib/doubleshot/resolver/gem_resolver/demand.rb +57 -0
  17. data/lib/doubleshot/resolver/gem_resolver/dependency.rb +57 -0
  18. data/lib/doubleshot/resolver/gem_resolver/errors.rb +37 -0
  19. data/lib/doubleshot/resolver/gem_resolver/gem_source.rb +58 -0
  20. data/lib/doubleshot/resolver/gem_resolver/graph.rb +200 -0
  21. data/lib/doubleshot/resolver/gem_resolver/solver.rb +279 -0
  22. data/lib/doubleshot/resolver/gem_resolver/solver/constraint_row.rb +29 -0
  23. data/lib/doubleshot/resolver/gem_resolver/solver/constraint_table.rb +35 -0
  24. data/lib/doubleshot/resolver/gem_resolver/solver/variable_row.rb +47 -0
  25. data/lib/doubleshot/resolver/gem_resolver/solver/variable_table.rb +59 -0
  26. data/lib/doubleshot/resolver/gem_resolver/source.rb +36 -0
  27. data/lib/doubleshot/resolver/jar_resolver.rb +1 -3
  28. data/lib/ruby/gem/requirement.rb +9 -0
  29. data/target/doubleshot.jar +0 -0
  30. data/test/compiler_spec.rb +31 -3
  31. data/test/configuration_spec.rb +11 -3
  32. data/test/dependencies/gem_dependency_spec.rb +3 -17
  33. data/test/dependencies/jar_dependency_spec.rb +20 -0
  34. data/test/helper.rb +3 -1
  35. data/test/helpers/stub_source.rb +120 -0
  36. data/test/lockfile_spec.rb +9 -17
  37. data/test/pom_spec.rb +31 -1
  38. data/test/resolver/gem_resolver/artifact_spec.rb +106 -0
  39. data/test/resolver/gem_resolver/demand_spec.rb +70 -0
  40. data/test/resolver/gem_resolver/dependency_spec.rb +33 -0
  41. data/test/resolver/gem_resolver/gem_source_spec.rb +28 -0
  42. data/test/resolver/gem_resolver/graph_spec.rb +239 -0
  43. data/test/resolver/gem_resolver/solver_spec.rb +449 -0
  44. data/test/resolver/gem_resolver/source_spec.rb +18 -0
  45. data/test/resolver/gem_resolver_spec.rb +102 -0
  46. metadata +35 -73
  47. data/lib/doubleshot/jar.rb +0 -62
data/Doubleshot CHANGED
@@ -4,18 +4,27 @@ Doubleshot.new do |config|
4
4
 
5
5
  config.project = "doubleshot"
6
6
  config.group = "org.sam.doubleshot"
7
- config.version = "0.2.0"
7
+ config.version = "0.3.0"
8
8
 
9
- config.gem "bundler", ">= 0"
10
-
11
- config.gem "rdoc", ">= 2.4.2"
12
- config.gem "perfer", ">= 0"
13
9
  config.gem "minitest", ">= 3.0.1"
14
10
  config.gem "minitest-wscolor", ">= 0"
15
11
  config.gem "listen", ">= 0.5.3"
16
12
  config.gem "rb-fsevent", ">= 0.9.1"
17
- config.gem "simplecov", ">= 0"
18
13
 
14
+ if ENV["TRAVIS"]
15
+ config.mvn_repository "http://maven.mirrors.travis-ci.org/nexus/content/groups/public/"
16
+ config.mvn_repository "http://maven.mirrors.travis-ci.org/nexus/content/repositories/apache/"
17
+ config.mvn_repository "http://maven.mirrors.travis-ci.org/nexus/content/repositories/sonatype/"
18
+ config.mvn_repository "http://maven.mirrors.travis-ci.org/nexus/content/repositories/codehaus-snapshots/"
19
+ config.mvn_repository "http://maven.mirrors.travis-ci.org/nexus/content/shadows/central-m1/"
20
+ config.mvn_repository "http://maven.mirrors.travis-ci.org/nexus/content/repositories/central/"
21
+ else
22
+ config.mvn_repository "https://nexus.codehaus.org/content/groups/public/"
23
+ config.mvn_repository "https://oss.sonatype.org/content/groups/public/"
24
+ config.mvn_repository "http://mirrors.ibiblio.org/pub/mirrors/maven2"
25
+ config.mvn_repository "http://repo1.maven.org/maven2"
26
+ end
27
+
19
28
  config.jar "org.sonatype.aether:aether-api:jar:1.13.1"
20
29
  config.jar "org.sonatype.aether:aether-util:jar:1.13.1"
21
30
  config.jar "org.sonatype.aether:aether-impl:jar:1.13.1"
@@ -26,6 +35,7 @@ Doubleshot.new do |config|
26
35
  config.jar "org.apache.maven.wagon:wagon-file:jar:2.2"
27
36
  config.jar "org.apache.maven.wagon:wagon-http:jar:2.2"
28
37
  config.jar "org.apache.maven.wagon:wagon-provider-api:jar:2.2"
38
+ config.jar "org.sonatype.sisu:sisu-guice:jar:3.0.3"
29
39
 
30
40
  config.gemspec do |spec|
31
41
  spec.summary = "Doubleshot is a build and dependency tool for mixed Java and Ruby projects"
@@ -0,0 +1,216 @@
1
+ h1. Doubleshot
2
+
3
+ Latest test results:
4
+
5
+ !https://secure.travis-ci.org/sam/doubleshot.png(Build Status)!:http://travis-ci.org/sam/doubleshot
6
+
7
+ Doubleshot aims to let you write Java, and Ruby in the same project, and streamline the dependency, testing and build process.
8
+
9
+ You can have dependencies on both Gems and JARs, and easily package it all up in a redistributable Gem or Unified JAR when you're ready to ship.
10
+
11
+ When you clone a Doubleshot project, you can run it just like any other Ruby script. There's no external tool you have to call. There's no setup or installation process for dependencies. That all happens on-demand. You only need to use the provided @doubleshot@ command if you want to run the (optional) testing sandbox, or prepare a package for release. If you'd rather directly execute your test files, use a @RakeTestTask@, or whatever, you're free to do that.
12
+
13
+ Happy coding!
14
+
15
+ * "Overview":#overview
16
+ * "Usage":#usage
17
+ ** "Requirements":#requirements
18
+ ** "Installation":#installation
19
+ ** "Project Layout":#project-layout
20
+ ** "Testing":#testing-two-ways
21
+ *** "Direct Execution":#direct-execution
22
+ *** "Sandbox Execution":#sandbox-execution
23
+ ** "Packaging":#packaging
24
+ * "Tips":#tips
25
+ ** "Nailgun Usage":#use-doubleshot-with-nailgun-for-great-success
26
+ * "FAQ":#faq
27
+
28
+ h2. Overview
29
+
30
+ *JRuby is amazing.*
31
+
32
+ Unfortunately there's no simple standard way to create a Ruby Gem that contains both Java and Ruby sources, with both JAR and Gem dependencies.
33
+
34
+ Before Doubleshot you'd probably use "Bundler":https://github.com/carlhuda/bundler to manage your Gem dependencies, "JBundler":https://github.com/mkristian/jbundler to manage your JAR dependencies and "Buildr":https://github.com/apache/buildr (which is built on top of Rake) to compile and package your project. That's _really_ cumbersome. Especially since Buildr wasn't built for this, (it's focus is _Java_ projects, as a substitute for Maven) and there really is very little documentation on how to accomplish your goals.
35
+
36
+ On top of that, you're now forced to run Rake and load these massive libraries even just to execute a single @TestCase@. And you'll have to run it every time. If you're a fan of TDD, you can realistically spend a substantial portion of your day just waiting for the JVM to load Maven, Bundler and Rake. Over. And Over. And Over.
37
+
38
+ It's *painful* is what it is.
39
+
40
+ You have a JRuby project with both Java and Ruby source files. You need to:
41
+
42
+ * Compile your Java
43
+ * Download JAR dependencies from a "Maven repository":http://mvnrepository.com/
44
+ * Download Gem dependencies from a "Rubygems server":https://github.com/sam/geminaboxplus
45
+ * Java Classes and Dependencies should be added to the @$CLASSPATH@ at runtime
46
+ * Write your tests in a single language (Ruby) using "Minitest":https://github.com/seattlerb/minitest
47
+ * Execute your Ruby normally, without the need for wrappers like Rake or @bundle exec@
48
+ * Automatically compile and reload Java sources on update, then execute the appropriate tests
49
+ * Reload your testing sandbox after updating Ruby sources without side-effects from previous versions code
50
+ * Package your mixed-language project and it's JAR dependencies into a Gem you can release
51
+ * Package a project and all it's dependencies up as a JAR so all you need on your server is Java
52
+
53
+ Here's what tools Doubleshot replaces in your workflow:
54
+
55
+ * Bundler
56
+ * JBundler
57
+ * GemPackageTask
58
+ * RakeTestTask
59
+ * Maven Dependencies
60
+ * Maven Assemblies
61
+ * Build tools like Ant or Buildr
62
+
63
+ h1. Usage
64
+
65
+ h2. Requirements
66
+
67
+ * Java 6 or later
68
+ * Maven
69
+ * JRuby 1.7 or later
70
+ * Ruby 1.9 syntax only
71
+
72
+ h2. Installation
73
+
74
+ bc. gem install doubleshot
75
+
76
+ h2. Project Layout
77
+
78
+ The *default* project using Doubleshot as it's build-tool will have the following layout:
79
+
80
+ bc.. ext/
81
+ java/
82
+ Hello.java # Java sources appear under the ext/java folder.
83
+ lib/
84
+ world.rb # Ruby sources go in the standard location.
85
+ test/
86
+ helper.rb
87
+ hello_spec.rb # specs match up to lib/**/*.rb or ext/java/**/*.java
88
+ world_spec.rb
89
+ Doubleshot # Your Doubleshot file replaces your project's gemspec
90
+ # and JBundler's Jarfile.
91
+
92
+ p. Your tests should be executable and look something like this:
93
+
94
+ bc.. #!/usr/local/env jruby
95
+
96
+ require_relative "helper.rb"
97
+
98
+ java_import org.sam.doubleshot.example.Hello
99
+
100
+ describe Hello do
101
+ it "must rock you" do
102
+ Hello.rock(:you).must_equal true
103
+ end
104
+ end
105
+
106
+ p. ...and @helper.rb@ would look something like this:
107
+
108
+ bc.. require "doubleshot"
109
+ require "minitest/autorun"
110
+
111
+ h2. Testing Two Ways
112
+
113
+ h3. Direct Execution
114
+
115
+ p. Now you can execute your spec file directly and Doubleshot will:
116
+
117
+ # Ensure that the dependencies defined in the @Doubleshot@ file are met by resolving their versions, downloading them, and adding them to your environment.
118
+ # Compile any code found in @ext/java@ that's not already compiled.
119
+
120
+ Then Minitest will run your test and exit when it's done.
121
+
122
+ h3. Sandbox Execution
123
+
124
+ Doubleshot also provides a @doubleshot@ bin file. Running @doubleshot test@ in your project's home directory will setup monitors for @lib/@ and @test/@ and wait for changes, applying the rules below to it's execution:
125
+
126
+ * When source under @ext/java/@ changes, it will be recompiled, reloaded, and matching tests searched for to execute
127
+ * When Ruby source under @lib/@ changes, your Ruby VM will be reloaded, and matching tests executed
128
+ * If any tests change, the sandbox will be reloaded (since tests are written in Ruby), and the test file executed
129
+ * If a @SIGINT@ (@^C@) is received, all tests will be loaded and executed
130
+ * If a second @SIGINT@ is received before execution of the full test-suite is finished, the monitor will exit cleanly
131
+
132
+ This is the typical use-case for day to day development of new projects/features when using Doubleshot to manage your build process. It allows you to write and test new code, without ever having to restart your Java VM, saving you ten seconds or so for every run, encouraging continuous testing so you can spend more time writing code, and less time waiting for processes to load.
133
+
134
+ For your continuous testing/integration (CI) environment, you can also run all your tests just once by using the --ci-test option:
135
+
136
+ bc. doubleshot test --ci-test
137
+
138
+ h2. Packaging
139
+
140
+ # TODO: This is all out of date...
141
+
142
+ Given a project named _Example_, then @example.gemspec@ would include your Gem dependencies (including "doubleshot") and your @Doubleshot@ file would include your JAR dependencies as well as pulling in your Gem dependencies from your gemspec. This way your project is backwards compatible with Rubygems and Bundler. When packaging your project, your JAR dependencies will be "vendored" into the gem you've built.
143
+
144
+ Within your project (ie: @lib/example.rb@) you'll @require "doubleshot"@. This will ensure any dependencies for your Gem are satisfied at runtime. If a dependency is already loaded, (an upstream project called @require "bundler/setup"@ for example) then Doubleshot will skip it.
145
+
146
+ If you're running inside of a @doubleshot/setup@ then requiring @doublehsot/setup@ will have no effect to avoid doubling up on the work.
147
+
148
+ To build a gem, run the @doubleshot build@ command on the command line. Doubleshot will ensure all dependencies are satisfied, compile your code, vendor any JAR dependencies and finally create a gem for you based on your @example.gemspec@ file.
149
+
150
+ If you want your build to be conditional upon passing tests, add the @test :minitest@ directive to your @Doubleshot@ file. If you need to temporarily skip the tests to build a gem with this option enabled, use @NOTEST=true doubleshot build@ to package your gem.
151
+
152
+ h1. Tips
153
+
154
+ h2. Use Doubleshot with Nailgun for Great Success!
155
+
156
+ Open a terminal window and navigate to the root of your project (to make sure you're using the right JRuby if you have an @.rvmrc@). Then run:
157
+
158
+ bc. jruby --ng-server &
159
+
160
+ Now run your code (any JRuby code, not just Doubleshot) as usual, but add the @--ng@ option to JRuby:
161
+
162
+ bc. jruby --ng -r lib/doubleshot/setup.rb -e "puts org.foo.Bar.baz"
163
+
164
+ It may take a few cycles while things warm up, but you should see this cut your process load-time by several seconds. It's especially handy if you're running lots of test cases directly as detailed in the first testing scenario. It could easily cut your testing time in half (or more).
165
+
166
+ When you're done for the day, just foreground the server with the @fg@ command, and @SIGINT@ it (@^C@) to quit.
167
+
168
+ h1. FAQ
169
+
170
+ h2. What's in a Name?
171
+
172
+ A shot each of JRuby and Java. Doubleshot.
173
+
174
+ h2. Where is @doubleshot show@?
175
+
176
+ Bundler includes a @bundle show some_gem@ command that shows you the path where a dependency was unpacked after running @bundle install@. I've only ever used that in two cases:
177
+
178
+ *View the source of some library to try to trace a bug:* Write a test to trace your bug. View the source online or clone it and view it locally. It's a minor inconvenience sure, but it's a lot less prone to abuse.
179
+
180
+ *Hack in a quick "hot-fix" for a production issue:* You shouldn't be making changes outside of source-control. That's an obvious development anti-pattern.
181
+
182
+ It's our opinion that you don't _need_ this functionality, and it opens the window to abuse, so we're not implementing it.
183
+
184
+ h2. I just ran @doubleshot install@ and I'm not sure what happened?
185
+
186
+ With Bundler it's common to:
187
+
188
+ # @bundle install@ to inspect your Gemfile and download/install any missing dependencies
189
+ # @require "bundler/setup"@ to check/require dependencies at runtime
190
+
191
+ With Doubleshot you'll just:
192
+
193
+ bc. require "doubleshot"
194
+
195
+ In your @test/helper.rb@ (or whatever common file you use for test bootstrapping). Or you can run @doubleshot test@.
196
+
197
+ Doubleshot will first see if all it's dependencies are available, and if not, install any that are missing. So you don't have to manually run an installation step.
198
+
199
+ If you run @doubleshot help@ you'll see that the @install@ command actually packages up your project as a Gem and installs it locally. So @doubleshot install@ is analogous to @gem install@, *not* @bundle install@.
200
+
201
+ bq.. But I just want to install my Gem dependencies on a remote server and not actually attempt to run any code!
202
+ *-- Said No One Ever*
203
+
204
+ p. If you _really_ want to pre-download your dependencies just run @doubleshot build@ in your project's home-directory. Dependencies will be installed as part of the build process.
205
+
206
+ h2. What if I want to create a unified JAR containing all my dependencies?
207
+
208
+ Use @doubleshot jar [main-class]@. By default the main-class will use JRuby's bootstrapping mechanism @org.jruby.JarBootstrapMain@, where you add your own @jar-bootstrap.rb@ file to be required.
209
+
210
+ All gems will be unpacked and copied in. All JAR dependencies will be copied in as well.
211
+
212
+ This will leave you with an @example.jar@ you can just copy up to a server, and as long as a compatible version of Java is installed (typically Java6 or later), you have everything you need to run your application bundled in. Now you just need to run @java -jar example.jar@ and you're off to the races!
213
+
214
+ h2. Does Doubleshot support Ruby 1.8.x syntax?
215
+
216
+ No.
data/README.textile CHANGED
@@ -4,213 +4,69 @@ Latest test results:
4
4
 
5
5
  !https://secure.travis-ci.org/sam/doubleshot.png(Build Status)!:http://travis-ci.org/sam/doubleshot
6
6
 
7
- Doubleshot aims to let you write Java, and Ruby in the same project, and streamline the dependency, testing and build process.
8
-
9
- You can have dependencies on both Gems and JARs, and easily package it all up in a redistributable Gem or Unified JAR when you're ready to ship.
10
-
11
- When you clone a Doubleshot project, you can run it just like any other Ruby script. There's no external tool you have to call. There's no setup or installation process for dependencies. That all happens on-demand. You only need to use the provided @doubleshot@ command if you want to run the (optional) testing sandbox, or prepare a package for release. If you'd rather directly execute your test files, use a @RakeTestTask@, or whatever, you're free to do that.
12
-
13
- Happy coding!
14
-
15
- * "Overview":#overview
16
- * "Usage":#usage
17
- ** "Requirements":#requirements
18
- ** "Installation":#installation
19
- ** "Project Layout":#project-layout
20
- ** "Testing":#testing-two-ways
21
- *** "Direct Execution":#direct-execution
22
- *** "Sandbox Execution":#sandbox-execution
23
- ** "Packaging":#packaging
24
- * "Tips":#tips
25
- ** "Nailgun Usage":#use-doubleshot-with-nailgun-for-great-success
26
- * "FAQ":#faq
27
-
28
7
  h2. Overview
29
8
 
30
- *JRuby is amazing.*
31
-
32
- Unfortunately there's no simple standard way to create a Ruby Gem that contains both Java and Ruby sources, with both JAR and Gem dependencies.
33
-
34
- Before Doubleshot you'd probably use "Bundler":https://github.com/carlhuda/bundler to manage your Gem dependencies, "JBundler":https://github.com/mkristian/jbundler to manage your JAR dependencies and "Buildr":https://github.com/apache/buildr (which is built on top of Rake) to compile and package your project. That's _really_ cumbersome. Especially since Buildr wasn't built for this, (it's focus is _Java_ projects, as a substitute for Maven) and there really is very little documentation on how to accomplish your goals.
9
+ Doubleshot is for Developers using JRuby.
35
10
 
36
- On top of that, you're now forced to run Rake and load these massive libraries even just to execute a single @TestCase@. And you'll have to run it every time. If you're a fan of TDD, you can realistically spend a substantial portion of your day just waiting for the JVM to load Maven, Bundler and Rake. Over. And Over. And Over.
11
+ It let's you write Java and Ruby, perform Continuous Testing (meaning whenever a file changes, both Java and Ruby code is sandboxed and reloaded and the appropriate tests run), and package it all up as a Gem or JAR.
37
12
 
38
- It's *painful* is what it is.
13
+ It's a substitute for writing your own Maven tasks, declaring Maven Dependencies, having Ruby dependencies managed by Bundler, and a Rakefile for packaging everything up as a Gem.
39
14
 
40
- You have a JRuby project with both Java and Ruby source files. You need to:
15
+ Before Doubleshot you might have a @Buildfile@ (using Buildr), @Jarfile@ and @Gemfile@. Or a @pom.xml@, @Gemfile@ and @Rakefile@. However you slice it, you'd be using multiple tools, with different syntaxes and styles, that required you to run them in a specific order to actually get your project to run.
41
16
 
42
- * Compile your Java
43
- * Download JAR dependencies from a "Maven repository":http://mvnrepository.com/
44
- * Download Gem dependencies from a "Rubygems server":https://github.com/sam/geminaboxplus
45
- * Java Classes and Dependencies should be added to the @$CLASSPATH@ at runtime
46
- * Write your tests in a single language (Ruby) using "Minitest":https://github.com/seattlerb/minitest
47
- * Execute your Ruby normally, without the need for wrappers like Rake or @bundle exec@
48
- * Automatically compile and reload Java sources on update, then execute the appropriate tests
49
- * Reload your testing sandbox after updating Ruby sources without side-effects from previous versions code
50
- * Package your mixed-language project and it's JAR dependencies into a Gem you can release
51
- * Package a project and all it's dependencies up as a JAR so all you need on your server is Java
17
+ Doubleshot simplifies all that. You have one Doubleshot file that defines your Gem dependencies, your JAR dependencies, and declares how to either test or package it all up as a Gem or a JAR. Once you have a Doubleshot file (take a look at the examples folder for some basics), then you have a few simple commands you can run to do what you need. Here's the output of @doubleshot help@:
52
18
 
53
- Here's what tools Doubleshot replaces in your workflow:
19
+ bc.. Usage: doubleshot COMMAND [ OPTIONS ]
54
20
 
55
- * Bundler
56
- * JBundler
57
- * GemPackageTask
58
- * RakeTestTask
59
- * Maven Dependencies
60
- * Maven Assemblies
61
- * Build tools like Ant or Buildr
21
+ Summary: Command line tool for creating and managing doubleshot projects.
62
22
 
63
- h1. Usage
23
+ doubleshot init # Generate a Doubleshot file for your project.
64
24
 
65
- h2. Requirements
25
+ doubleshot test # A test harness that watches files, builds your
26
+ # source, and executes tests based on filename
27
+ # conventions. The location of your tests is
28
+ # determined by the 'config.source.tests'
29
+ # attribute of your Doubleshot configuration.
66
30
 
67
- * Java 6 or later
68
- * Maven
69
- * JRuby 1.7 or later
70
- * Ruby 1.9 syntax only
31
+ doubleshot build # Download all dependencies and compile sources so that you
32
+ # can use the project directly without installation, such
33
+ # as with IRB.
34
+ #
35
+ # NOTE: Packaging and testing have a dependency on this
36
+ # command. You don't need to build as a prerequisite.
71
37
 
72
- h2. Installation
38
+ doubleshot gem # Package your project as a Rubygem, bundling any
39
+ # JAR dependencies and Java classes in with the distribution.
73
40
 
74
- bc. gem install doubleshot
41
+ doubleshot jar # Package your project as a JAR.
75
42
 
76
- h2. Project Layout
43
+ doubleshot install # Install your project as a Rubygem.
77
44
 
78
- The *default* project using Doubleshot as it's build-tool will have the following layout:
45
+ doubleshot pom # Generate a pom.xml based on your Doubleshot file.
79
46
 
80
- bc.. ext/
81
- java/
82
- Hello.java # Java sources appear under the ext/java folder.
83
- lib/
84
- world.rb # Ruby sources go in the standard location.
85
- test/
86
- helper.rb
87
- hello_spec.rb # specs match up to lib/**/*.rb or ext/java/**/*.java
88
- world_spec.rb
89
- Doubleshot # Your Doubleshot file replaces your project's gemspec
90
- # and JBundler's Jarfile.
47
+ p. To get a descriptive @Doubleshot@ that comments all the options, just run @doubleshot init@ in your project. It'll read existing @myproject.gemspec@ and @pom.xml@ files, and use them to generate a Doubleshot file. Take a look at the @Doubleshot.example@ file in this project if you just want to read up now.
91
48
 
92
- p. Your tests should be executable and look something like this:
49
+ Pro-Tip: Similarly to a @Gem::Specification@, a @Doubleshot::Configuration@ provides a @#to_ruby@ method, so that example was generated in IRB from the actual project configuration (the existing @Doubleshot@ file in the project) like this:
93
50
 
94
- bc.. #!/usr/local/env jruby
95
-
96
- require_relative "helper.rb"
97
-
98
- java_import org.sam.doubleshot.example.Hello
99
-
100
- describe Hello do
101
- it "must rock you" do
102
- Hello.rock(:you).must_equal true
103
- end
51
+ bc.. require "lib/doubleshot"
52
+ Pathname("Doubleshot.example").open("w+") do |example|
53
+ example << Doubleshot::current.config.to_ruby
104
54
  end
105
55
 
106
- p. ...and @helper.rb@ would look something like this:
107
-
108
- bc.. require "doubleshot"
109
- require "minitest/autorun"
110
-
111
- h2. Testing Two Ways
112
-
113
- h3. Direct Execution
114
-
115
- p. Now you can execute your spec file directly and Doubleshot will:
116
-
117
- # Ensure that the dependencies defined in the @Doubleshot@ file are met by resolving their versions, downloading them, and adding them to your environment.
118
- # Compile any code found in @ext/java@ that's not already compiled.
119
-
120
- Then Minitest will run your test and exit when it's done.
121
-
122
- h3. Sandbox Execution
123
-
124
- Doubleshot also provides a @doubleshot@ bin file. Running @doubleshot test@ in your project's home directory will setup monitors for @lib/@ and @test/@ and wait for changes, applying the rules below to it's execution:
125
-
126
- * When source under @ext/java/@ changes, it will be recompiled, reloaded, and matching tests searched for to execute
127
- * When Ruby source under @lib/@ changes, your Ruby VM will be reloaded, and matching tests executed
128
- * If any tests change, the sandbox will be reloaded (since tests are written in Ruby), and the test file executed
129
- * If a @SIGINT@ (@^C@) is received, all tests will be loaded and executed
130
- * If a second @SIGINT@ is received before execution of the full test-suite is finished, the monitor will exit cleanly
131
-
132
- This is the typical use-case for day to day development of new projects/features when using Doubleshot to manage your build process. It allows you to write and test new code, without ever having to restart your Java VM, saving you ten seconds or so for every run, encouraging continuous testing so you can spend more time writing code, and less time waiting for processes to load.
133
-
134
- For your continuous testing/integration (CI) environment, you can also run all your tests just once by using the --ci-test option:
135
-
136
- bc. doubleshot test --ci-test
137
-
138
- h2. Packaging
139
-
140
- # TODO: This is all out of date...
141
-
142
- Given a project named _Example_, then @example.gemspec@ would include your Gem dependencies (including "doubleshot") and your @Doubleshot@ file would include your JAR dependencies as well as pulling in your Gem dependencies from your gemspec. This way your project is backwards compatible with Rubygems and Bundler. When packaging your project, your JAR dependencies will be "vendored" into the gem you've built.
143
-
144
- Within your project (ie: @lib/example.rb@) you'll @require "doubleshot"@. This will ensure any dependencies for your Gem are satisfied at runtime. If a dependency is already loaded, (an upstream project called @require "bundler/setup"@ for example) then Doubleshot will skip it.
145
-
146
- If you're running inside of a @doubleshot/setup@ then requiring @doublehsot/setup@ will have no effect to avoid doubling up on the work.
147
-
148
- To build a gem, run the @doubleshot build@ command on the command line. Doubleshot will ensure all dependencies are satisfied, compile your code, vendor any JAR dependencies and finally create a gem for you based on your @example.gemspec@ file.
149
-
150
- If you want your build to be conditional upon passing tests, add the @test :minitest@ directive to your @Doubleshot@ file. If you need to temporarily skip the tests to build a gem with this option enabled, use @NOTEST=true doubleshot build@ to package your gem.
151
-
152
- h1. Tips
153
-
154
- h2. Use Doubleshot with Nailgun for Great Success!
155
-
156
- Open a terminal window and navigate to the root of your project (to make sure you're using the right JRuby if you have an @.rvmrc@). Then run:
157
-
158
- bc. jruby --ng-server &
159
-
160
- Now run your code (any JRuby code, not just Doubleshot) as usual, but add the @--ng@ option to JRuby:
161
-
162
- bc. jruby --ng -r lib/doubleshot/setup.rb -e "puts org.foo.Bar.baz"
163
-
164
- It may take a few cycles while things warm up, but you should see this cut your process load-time by several seconds. It's especially handy if you're running lots of test cases directly as detailed in the first testing scenario. It could easily cut your testing time in half (or more).
165
-
166
- When you're done for the day, just foreground the server with the @fg@ command, and @SIGINT@ it (@^C@) to quit.
167
-
168
- h1. FAQ
169
-
170
- h2. What's in a Name?
171
-
172
- A shot each of JRuby and Java. Doubleshot.
173
-
174
- h2. Where is @doubleshot show@?
175
-
176
- Bundler includes a @bundle show some_gem@ command that shows you the path where a dependency was unpacked after running @bundle install@. I've only ever used that in two cases:
177
-
178
- *View the source of some library to try to trace a bug:* Write a test to trace your bug. View the source online or clone it and view it locally. It's a minor inconvenience sure, but it's a lot less prone to abuse.
179
-
180
- *Hack in a quick "hot-fix" for a production issue:* You shouldn't be making changes outside of source-control. That's an obvious development anti-pattern.
181
-
182
- It's our opinion that you don't _need_ this functionality, and it opens the window to abuse, so we're not implementing it.
183
-
184
- h2. I just ran @doubleshot install@ and I'm not sure what happened?
185
-
186
- With Bundler it's common to:
187
-
188
- # @bundle install@ to inspect your Gemfile and download/install any missing dependencies
189
- # @require "bundler/setup"@ to check/require dependencies at runtime
190
-
191
- With Doubleshot you'll just:
192
-
193
- bc. require "doubleshot"
194
-
195
- In your @test/helper.rb@ (or whatever common file you use for test bootstrapping). Or you can run @doubleshot test@.
196
-
197
- Doubleshot will first see if all it's dependencies are available, and if not, install any that are missing. So you don't have to manually run an installation step.
198
-
199
- If you run @doubleshot help@ you'll see that the @install@ command actually packages up your project as a Gem and installs it locally. So @doubleshot install@ is analogous to @gem install@, *not* @bundle install@.
56
+ h2. Development
200
57
 
201
- bq.. But I just want to install my Gem dependencies on a remote server and not actually attempt to run any code!
202
- *-- Said No One Ever*
58
+ Here's how to get Doubleshot running locally yourself. You'll need Java, Maven, JRuby (1.7.x or -head) and Bundler installed. Then, clone the repo:
203
59
 
204
- p. If you _really_ want to pre-download your dependencies just run @doubleshot build@ in your project's home-directory. Dependencies will be installed as part of the build process.
60
+ bc. git clone git://github.com/sam/doubleshot.git
205
61
 
206
- h2. What if I want to create a unified JAR containing all my dependencies?
62
+ The last milestone we're currently working on is Gem resolution. For right now, you'll need to bootstrap the build with Bundler:
207
63
 
208
- Use @doubleshot jar [main-class]@. By default the main-class will use JRuby's bootstrapping mechanism @org.jruby.JarBootstrapMain@, where you add your own @jar-bootstrap.rb@ file to be required.
64
+ bc. bundle install
209
65
 
210
- All gems will be unpacked and copied in. All JAR dependencies will be copied in as well.
66
+ Doubleshot bootstraps it's own build using a slightly different process than used for projects actually using it. It's a chicken and egg situation. Since Doubleshot depends on some Java code to resolve JAR dependencies, and we can't compile without our dependencies, we can't use Doubleshot's normal code to resolve it's own JAR dependencies. That's why Doubleshot has a @pom.xml@ (generated with the @doubleshot pom@ command). We shell out to the Maven command line while bootstrapping the build.
211
67
 
212
- This will leave you with an @example.jar@ you can just copy up to a server, and as long as a compatible version of Java is installed (typically Java6 or later), you have everything you need to run your application bundled in. Now you just need to run @java -jar example.jar@ and you're off to the races!
68
+ All that just to clarify the process. Once you've installed your Gem dependencies with Bundler, the only thing left you actually need to do at this point is run one of the @doubleshot@ commands to package or test. The internal bootstrapping will take care of the rest:
213
69
 
214
- h2. Does Doubleshot support Ruby 1.8.x syntax?
70
+ bc. bin/doubleshot test --ci
215
71
 
216
- No.
72
+ Happy coding!