hydra-head 4.0.0.rc5 → 4.0.0.rc6
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- data/HISTORY.textile +1 -1
- data/HOW_TO_GET_STARTED.textile +2 -2
- data/INSTALL_PREREQ.textile +1 -20
- data/README.textile +12 -16
- data/app/assets/stylesheets/hydra/html_refactor.css +1 -5
- data/app/assets/stylesheets/hydra/hydrangea.css +0 -4
- data/app/assets/stylesheets/hydra/styles.css +12 -595
- data/app/controllers/downloads_controller.rb +2 -1
- data/app/controllers/hydra/permissions_controller.rb +2 -6
- data/app/models/ability.rb +1 -98
- data/app/models/hydra/ability.rb +128 -0
- data/app/views/_flash_msg.html.erb +1 -1
- data/app/views/catalog/_home.html.erb +2 -2
- data/app/views/catalog/_home_text.html.erb +2 -8
- data/app/views/catalog/_show_partials/_default.html.erb +0 -4
- data/app/views/generic_images/_edit.html.erb +0 -2
- data/app/views/layouts/hydra-head.html.erb +22 -35
- data/lib/hydra-head/version.rb +1 -1
- data/lib/hydra/mods_article.rb +22 -2
- data/lib/railties/hydra-fixtures.rake +17 -24
- data/tasks/hydra-head-fixtures.rake +32 -28
- data/tasks/hydra-head.rake +39 -57
- data/{lib/railties → tasks}/hyhead_rspec.rake +7 -26
- data/test_support/features/file_upload.feature +3 -3
- data/test_support/features/step_definitions/edit_metadata_steps.rb +1 -1
- data/test_support/features/step_definitions/user_steps.rb +7 -4
- data/test_support/spec/models/ability_spec.rb +3 -9
- metadata +36 -51
- data/DEVELOP_PLUGIN.textile +0 -90
- data/GIT_WORKFLOW.textile +0 -106
- data/HOW_TO_DEFINE_A_HYDRA_CONTROLLER.textile +0 -21
- data/HOW_TO_DEFINE_A_HYDRA_MODEL.textile +0 -64
- data/HYDRA_ACCESS_CONTROLS.textile +0 -27
- data/INITIAL_APP_MODS.textile +0 -223
- data/README_RAILS3_CHANGES.textile +0 -67
- data/README_RAKE_TASKS.textile +0 -107
- data/README_SUBTREE.textile +0 -87
- data/README_TERSE.textile +0 -92
- data/RELEASE_NOTES.textile +0 -8
- data/TESTING.textile +0 -85
- data/TESTING_PLUGIN.textile +0 -133
- data/app/views/layouts/application.html.erb +0 -49
- data/lib/railties/all_tests.rake +0 -23
- data/lib/railties/hyhead_cucumber.rake +0 -126
@@ -1,67 +0,0 @@
|
|
1
|
-
|
2
|
-
h2. Views
|
3
|
-
|
4
|
-
Security has been tightened in Rails3, forcing you to include _authenticity_token__ with all requests. If you have forms or javascript that submits requests without this token, Rails will destroy the user session, effectively logging the user out (see http://weblog.rubyonrails.org/2011/2/8/csrf-protection-bypass-in-ruby-on-rails). The easiest way to make sure this token is properly included in your forms is to generate the forms using the +form_tag+ or +form_for+ view helpers from Rails.
|
5
|
-
|
6
|
-
h2. Fixtures
|
7
|
-
|
8
|
-
Fixtures are loaded from a directory _within the test app_, which is updated when you run rake hyhead:setup_test_app so in order to update a fixture, you must change it in test_support/fixtures and then either re-run rake hyhead:setup_test_app or copy the fixture into tmp/test_app/test_support/fixtures
|
9
|
-
|
10
|
-
h2. Cucumber tests
|
11
|
-
|
12
|
-
We have switched from Webrat to Capybara as the driver for our Cucumber tests. If you have been writing your own cucumber tests (you should!) and want to stay in sync with the rest of the hydra developers, you should switch to Capybara and pull all of the "step definitions from the hydra code":https://github.com/projecthydra/hydra-head/tree/rails3/test_support/features/step_definitions into your local app.
|
13
|
-
|
14
|
-
Sometime soon, we hope to wrap our step definitions into the Hydra code itself so that you can use them without having to manually copy the files into your step_definitions directory. This will probably be done in a way that imitates the "Factory Girl step definitions":http://robots.thoughtbot.com/post/284805810/gimme-three-steps
|
15
|
-
|
16
|
-
h2. User objects
|
17
|
-
|
18
|
-
Blacklight has switched to using devise instead of authlogic as its default user/authentication system. As part of this switch, no longer have a "login" attribute as their unique identifier. Instead, you must use email as the unique identifier. We have added a "login" method that
|
19
|
-
|
20
|
-
h2. User Attributes
|
21
|
-
|
22
|
-
User attributes (first_name, last_name, full_name, affiliation and photo) have been removed from HydraHead.
|
23
|
-
|
24
|
-
h2. Controllers
|
25
|
-
|
26
|
-
* Removed Djatoka (JPEG 2000) support and the GetController
|
27
|
-
|
28
|
-
h2. Views
|
29
|
-
|
30
|
-
* removed fluid infusion javascript
|
31
|
-
* moved javascripts from the plugin directory. Update your views to remove ":plugin=>:hydra_repository"
|
32
|
-
|
33
|
-
h3. What this means:
|
34
|
-
|
35
|
-
* Our sample user "archivist1" is now "archivist1@example.com".
|
36
|
-
* Your cucumber features and rspec tests must use email addresses as the unique identifier for Users
|
37
|
-
|
38
|
-
Change your features and role_map YAML files accordingly.
|
39
|
-
|
40
|
-
|
41
|
-
|
42
|
-
|
43
|
-
h2. How to upgrade
|
44
|
-
|
45
|
-
The sureest and easiest path to upgrading a hydra head application from Rails 2 to Rails 3, is to start a new project from scratch.
|
46
|
-
|
47
|
-
* Create a new rails 3 project
|
48
|
-
* Add ```gem 'blacklight'``` and ```gem 'hydra-head'``` to the Gemfile
|
49
|
-
* run ```bundle install```
|
50
|
-
* cp -r old_project/vendor/plugin/old_project_plugin/app/* new_project/app
|
51
|
-
* cp -r old_project/vendor/plugin/old_project_plugin/lib/* new_project/lib
|
52
|
-
<<<<<<< HEAD
|
53
|
-
* copy any tests (test, spec, feature, etc) from the old_project_plugin directory to the new project
|
54
|
-
* Run the generators
|
55
|
-
```rails g blackight -devise```
|
56
|
-
Run the hydra-head generator
|
57
|
-
```rails g hydra:head -df```
|
58
|
-
Run the database migrations
|
59
|
-
```rake db:migrate
|
60
|
-
rake db:migrate RAILS_ENV=test```
|
61
|
-
|
62
|
-
* If you will be writing cucumber tests, run the cucumber generator
|
63
|
-
```rails g cucumber:install```
|
64
|
-
* copy any tests (test, spec, feature, etc) from the old_project_plugin directory to the new project
|
65
|
-
* update your solrconfig.xml
|
66
|
-
* update your role_map_...yml files to use appropriate identifiers
|
67
|
-
|
data/README_RAKE_TASKS.textile
DELETED
@@ -1,107 +0,0 @@
|
|
1
|
-
h2. Getting info about the rake tasks from the command line
|
2
|
-
|
3
|
-
<pre>rake -T</pre>
|
4
|
-
|
5
|
-
To narrow down the output, use grep. For example:
|
6
|
-
|
7
|
-
<pre>rake -T | grep hy</pre>
|
8
|
-
|
9
|
-
|
10
|
-
h2. hydra:jetty Tasks
|
11
|
-
|
12
|
-
h3. The main tasks: load, start, stop
|
13
|
-
|
14
|
-
<pre>
|
15
|
-
rake hydra:jetty:load # Copies the default SOLR config files and starts up the fedora instance.
|
16
|
-
rake hydra:jetty:restart # Restarts the bundled Hydra Testing Server
|
17
|
-
rake hydra:jetty:start # Starts the bundled Hydra Testing Server
|
18
|
-
rake hydra:jetty:status # Returns the status of the Hydra::TestingServer.
|
19
|
-
rake hydra:jetty:stop # Stops the bundled Hydra Testing Server
|
20
|
-
</pre>
|
21
|
-
|
22
|
-
h3. Subtasks: config, config_fedora, config_solr
|
23
|
-
|
24
|
-
<pre>
|
25
|
-
rake hydra:jetty:config # Copies the default Solr & Fedora configs into the bundled Hydra Testing Server
|
26
|
-
rake hydra:jetty:config_fedora # Copies a custom fedora config for the bundled Hydra Testing Server
|
27
|
-
rake hydra:jetty:config_solr # Copies the default SOLR config for the bundled Hydra Testing Server
|
28
|
-
</pre>
|
29
|
-
|
30
|
-
h2. hyhead Continuous Integration Tasks
|
31
|
-
|
32
|
-
h3. hyhead Full Continuous Integration Build: ci
|
33
|
-
|
34
|
-
<pre>
|
35
|
-
rake hyhead:ci # Execute Continuous Integration build (docs, tests with coverage)
|
36
|
-
</pre>
|
37
|
-
|
38
|
-
h2. hyhead Test Host Setup: setup_test_host
|
39
|
-
|
40
|
-
Many of the other tasks call this for you.
|
41
|
-
|
42
|
-
<pre>
|
43
|
-
rake hyhead:setup_test_host # Copy all of the necessary code into the test host
|
44
|
-
</pre>
|
45
|
-
|
46
|
-
h3. Subtasks for setting up test host
|
47
|
-
|
48
|
-
These are the tasks used by setup_test_host
|
49
|
-
|
50
|
-
<pre>
|
51
|
-
rake hyhead:copy_plugin_to_host # Copy the current plugin code into hydra-plugin_test_host/vendor/plugins/hydra-head
|
52
|
-
rake hyhead:remove_plugin_from_host # Remove hydra-plugin_test_host/vendor/plugins/hydra-head
|
53
|
-
rake hyhead:copy_features_to_host # Copy current contents of the features directory into hydra-plugin_test_host/features
|
54
|
-
rake hyhead:remove_features_from_host # Remove hydra-plugin_test_host/features
|
55
|
-
rake hyhead:copy_fixtures_to_host # Copy current contents of the spec/fixtures directory into hydra-plugin_test_host/spec/fixtures
|
56
|
-
rake hyhead:remove_fixtures_from_host # Remove hydra-plugin_test_host/spec/fixtures
|
57
|
-
</pre>
|
58
|
-
|
59
|
-
h2. hyhead RSpec Tasks
|
60
|
-
|
61
|
-
h3. The main RSpec task: spec
|
62
|
-
|
63
|
-
<pre>
|
64
|
-
rake hyhead:spec # Easiest way to run rspec tests.
|
65
|
-
</pre>
|
66
|
-
|
67
|
-
This is the same as calling
|
68
|
-
|
69
|
-
<pre>
|
70
|
-
rake hyhead:rspec:setup_and_run # Sets up test host, loads fixtures, then runs specs - need to have jetty running.
|
71
|
-
</pre>
|
72
|
-
|
73
|
-
h4. Rspec subtasks
|
74
|
-
|
75
|
-
To run the rspec tests without any setup, use
|
76
|
-
|
77
|
-
<pre>
|
78
|
-
rake hyhead:rspec:run # Run the hydra-head specs - need to have jetty running, test host set up and fixtures loaded.
|
79
|
-
</pre>
|
80
|
-
|
81
|
-
h2. hyhead Cucumber Tasks
|
82
|
-
|
83
|
-
h3. The main Cucumber task: cucumber
|
84
|
-
|
85
|
-
<pre>
|
86
|
-
rake hyhead:cucumber # Easieset way to run cucumber tests.
|
87
|
-
</pre>
|
88
|
-
|
89
|
-
This is the same as calling
|
90
|
-
|
91
|
-
<pre>
|
92
|
-
rake hyhead:cucumber:setup_and_run # Sets up test host, loads fixtures, then runs cucumber features - need to have jetty running.
|
93
|
-
</pre>
|
94
|
-
|
95
|
-
h3. Cucumber subtasks
|
96
|
-
|
97
|
-
To run the cucumber tests without any setup, use
|
98
|
-
|
99
|
-
<pre>
|
100
|
-
rake hyhead:cucumber:run # Run cucumber tests for hyhead - need to have jetty running, test host set up and fixtures loaded.
|
101
|
-
</pre>
|
102
|
-
|
103
|
-
h3. Generating RDocs
|
104
|
-
|
105
|
-
<pre>
|
106
|
-
rake hyhead:doc # Generate YARD Documentation
|
107
|
-
</pre>
|
data/README_SUBTREE.textile
DELETED
@@ -1,87 +0,0 @@
|
|
1
|
-
h1. Tracking Plugins with Git Subtree
|
2
|
-
|
3
|
-
We are now tracking all of the Hydra plugins in their own Git repositories. We are doing this with the git subtree tool. This allows each hydra head to have a full copy of each plugin in its working copy. When you want to commit plugin changes back to the shared plugin git repository, use the git subtree tool to "split" that plugin's code and commit log into its own branch, then merge your changes into the shared plugin repository.
|
4
|
-
|
5
|
-
h2. Getting the git subtree tool
|
6
|
-
|
7
|
-
You can checkout the git subtree tool from https://github.com/apenwarr/git-subtree
|
8
|
-
|
9
|
-
The tool itself is just a single-file shell script that you need to install into where the rest of your git scripts are stored. See the "INSTALL instructions":https://github.com/apenwarr/git-subtree/blob/master/INSTALL
|
10
|
-
|
11
|
-
Once you've got it installed, refer to "git-subtree.txt":https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt for details on how to use the script. For our purposes, you can mostly rely on the info below.
|
12
|
-
|
13
|
-
h2. Using the git subtree tool
|
14
|
-
|
15
|
-
Say I'm working on the HyHull project and I need to commit changes from my head back to the shared hydrangea_articles plugin
|
16
|
-
|
17
|
-
First, add the hydrangea_articles git repository to your remote repositories
|
18
|
-
|
19
|
-
<pre>
|
20
|
-
git remote add articles-repo git@github.com:projecthydra/hydrangea_articles.git
|
21
|
-
</pre>
|
22
|
-
|
23
|
-
Then, use git subtree to split your copy of the plugin into a new branch in your local git repository. Include the name of your hydra head in the --annotate value. This will be appended to all of your commits.
|
24
|
-
|
25
|
-
<pre>
|
26
|
-
git subtree split --prefix=vendor/plugins/hydrangea_articles --annotate="(HyHull) " -b articles
|
27
|
-
</pre>
|
28
|
-
|
29
|
-
This will create a new branch called "articles"
|
30
|
-
|
31
|
-
Now checkout your articles branch, rebase to the master branch of the shared plugin, and then push your changes to the shared plugin
|
32
|
-
|
33
|
-
<pre>
|
34
|
-
git checkout articles
|
35
|
-
git rebase articles-repo/master
|
36
|
-
git push articles-repo articles:master
|
37
|
-
</pre>
|
38
|
-
|
39
|
-
If you don't want to push your updates directly into the master branch of the shared plugin, push to a new remote branch with the name of the ticket you're working on and ask another committer to review your changes and/or apply them.
|
40
|
-
|
41
|
-
<pre>
|
42
|
-
git push articles-repo articles:my-ticket-number
|
43
|
-
</pre>
|
44
|
-
|
45
|
-
If you just want to share a replica of your copy of the plugin without rebasing, you can use git subtree push to post a copy of your work as a branch on the shared plugin's git repo:
|
46
|
-
|
47
|
-
Ex:
|
48
|
-
</pre>
|
49
|
-
git subtree push --prefix=vendor/plugins/hydrangea_books --annotate="(HyHull) " -b HYHULL-219
|
50
|
-
<pre>
|
51
|
-
|
52
|
-
Complete example with shell outputs:
|
53
|
-
|
54
|
-
In this example, I
|
55
|
-
|
56
|
-
* split the plugin subtree into its own branch
|
57
|
-
* checkout the new plugin branch
|
58
|
-
* rebase the plugin branch against the plugin repository's master branch
|
59
|
-
* push my updates into the plugin repository's master branch
|
60
|
-
|
61
|
-
<pre>
|
62
|
-
hydrangea matt$ git subtree split --prefix=vendor/plugins/hydrangea_datasets --annotate="(hydrangea) " -b datasets
|
63
|
-
Created branch 'datasets'
|
64
|
-
f2d9407ada9744f3b8bcabac83ddb1cd3fb47e28
|
65
|
-
|
66
|
-
hydrangea matt$ git checkout datasets
|
67
|
-
warning: unable to rmdir jetty: Directory not empty
|
68
|
-
Checking out files: 100% (4723/4723), done.
|
69
|
-
Switched to branch 'datasets'
|
70
|
-
|
71
|
-
hydrangea matt$ git fetch datasets-remote
|
72
|
-
From github.com:projecthydra/hydrangea_datasets
|
73
|
-
* [new branch] master -> datasets-remote/master
|
74
|
-
|
75
|
-
hydrangea matt$ git rebase datasets-remote/master
|
76
|
-
First, rewinding head to replay your work on top of it...
|
77
|
-
Applying: (hydrangea) fixing licenses in plugins
|
78
|
-
|
79
|
-
hydrangea matt$ git push datasets datasets-remote:master
|
80
|
-
Counting objects: 4, done.
|
81
|
-
Delta compression using up to 2 threads.
|
82
|
-
Compressing objects: 100% (3/3), done.
|
83
|
-
Writing objects: 100% (3/3), 708 bytes, done.
|
84
|
-
Total 3 (delta 1), reused 0 (delta 0)
|
85
|
-
To git@github.com:projecthydra/hydrangea_datasets.git
|
86
|
-
656bf34..20ba2ba datasets -> master
|
87
|
-
</pre>
|
data/README_TERSE.textile
DELETED
@@ -1,92 +0,0 @@
|
|
1
|
-
h2. Installation/Setup
|
2
|
-
|
3
|
-
h3. (1) Grab the code
|
4
|
-
|
5
|
-
<pre>
|
6
|
-
git clone git@github.com:projecthydra/hydra-head.git
|
7
|
-
</pre>
|
8
|
-
|
9
|
-
h3. (2) Grab jetty and the test host application
|
10
|
-
|
11
|
-
The git repository includes references to git submodules containing hydra-jetty and a sample Blacklight app that you can install the hydra-head plugin into.
|
12
|
-
|
13
|
-
<pre>
|
14
|
-
cd hydra-head
|
15
|
-
git submodule init
|
16
|
-
git submodule update
|
17
|
-
bundle install
|
18
|
-
</pre>
|
19
|
-
|
20
|
-
|
21
|
-
h3. (3) IMPORTANT: Put a copy of the plugin into the host app
|
22
|
-
|
23
|
-
*If you don't run this, you will not be able to run the test host app or its rake tasks*
|
24
|
-
|
25
|
-
The host application needs a copy of the plugin in its vendor/plugins directory. We provide a rake task for this. The rake task will copy all of the plugin code into hydra-plugin_test_host/vendor/plugins
|
26
|
-
|
27
|
-
<pre>
|
28
|
-
rake hyhead:copy_to_host_plugins_dir
|
29
|
-
</pre>
|
30
|
-
|
31
|
-
|
32
|
-
h3. (4) Migrate the host app's databases
|
33
|
-
|
34
|
-
<pre>
|
35
|
-
cd hydra-plugin_test_host
|
36
|
-
rake db:drop:all
|
37
|
-
rake db:migrate
|
38
|
-
rake db:migrate RAILS_ENV=test
|
39
|
-
cd ..
|
40
|
-
</pre>
|
41
|
-
|
42
|
-
h2. Running the full Continuous Integration build
|
43
|
-
|
44
|
-
_Stop any copies of jetty that you have running before running this._
|
45
|
-
|
46
|
-
This will spin up jetty, import your fixtures into it run the tests, and stop jetty.
|
47
|
-
|
48
|
-
<pre>
|
49
|
-
rake hyhead:ci RAILS_ENV=test
|
50
|
-
</pre>
|
51
|
-
|
52
|
-
h2. Running the Tests Manually
|
53
|
-
|
54
|
-
h3. Start Jetty and load the fixtures
|
55
|
-
|
56
|
-
<pre>
|
57
|
-
rake hydra:jetty:load RAILS_ENV=test
|
58
|
-
rake hydra:default_fixtures:refresh environment=test
|
59
|
-
</pre>
|
60
|
-
|
61
|
-
h3. Run the RSpec Tests
|
62
|
-
|
63
|
-
<pre>
|
64
|
-
rake hyhead:spec
|
65
|
-
</pre>
|
66
|
-
|
67
|
-
OR
|
68
|
-
|
69
|
-
<pre>
|
70
|
-
rake hyhead:remove_from_host_plugins_dir
|
71
|
-
rake hyhead:copy_to_host_plugins_dir
|
72
|
-
rake hyhead:rspec
|
73
|
-
</pre>
|
74
|
-
|
75
|
-
|
76
|
-
h2. Running the App
|
77
|
-
|
78
|
-
The test host app is a regular Rails app with Blacklight installed. Its configured with the assumption that the hydra-head plugin is installed into vendor/plugins/hydra-head.
|
79
|
-
|
80
|
-
Before starting the app, make sure that you have the latest copy of the plugin code copied into its plugins directory.
|
81
|
-
|
82
|
-
<pre>
|
83
|
-
rake hyhead:remove_from_host_plugin
|
84
|
-
rake hyhead:copy_to_host_plugins_dir
|
85
|
-
</pre>
|
86
|
-
|
87
|
-
After copying the plugin code, cd into the root of the test app and start it like you normally start any rails app.
|
88
|
-
|
89
|
-
<pre>
|
90
|
-
cd hydra-plugin_test_host
|
91
|
-
script/server
|
92
|
-
</pre>
|
data/RELEASE_NOTES.textile
DELETED
@@ -1,8 +0,0 @@
|
|
1
|
-
h2. 3.0.0
|
2
|
-
|
3
|
-
If you have been testing out the Release Candidates, you need to add this line to your CatalogController:
|
4
|
-
|
5
|
-
<pre>
|
6
|
-
# This filters out objects that you want to exclude from search results. By default, it filters out FileAssets
|
7
|
-
CatalogController.solr_search_params_logic << :exclude_unwanted_models
|
8
|
-
</pre>
|
data/TESTING.textile
DELETED
@@ -1,85 +0,0 @@
|
|
1
|
-
h1. Directions to Clone and Test the Rails 3 hydra-head Code
|
2
|
-
|
3
|
-
h2. For the Impatient
|
4
|
-
|
5
|
-
# clone the hydra-head code (to a fresh working copy) <pre>git clone git@github.com:projecthydra/hydra-head.git</pre>
|
6
|
-
# switch tot he hydra-head directory <pre>cd hydra-head</pre>
|
7
|
-
# install bundler gem <pre>gem install bundler</pre>
|
8
|
-
# Get the project dependencies <pre>bundle install</pre>
|
9
|
-
# grab the jetty submodule <pre>git submodule init; git submodule update</pre>
|
10
|
-
# test <pre>rake hyhead:ci</pre> This command:
|
11
|
-
## creates the test app in tmp/test_app
|
12
|
-
## spins up jetty (in jettywrapper)
|
13
|
-
## imports fixtures
|
14
|
-
## runs rspec & cucumber tests
|
15
|
-
## kills jetty (in jettywrapper)
|
16
|
-
|
17
|
-
h2. More Detailed Instructions & Notes
|
18
|
-
|
19
|
-
h3. The Hydra Jetty
|
20
|
-
|
21
|
-
In order to test the gem during development, the hydra-jetty is included as a submodule to provide both a fedora and solr instance. Once you have cloned the github repository,
|
22
|
-
run the following commands to load the jetty:
|
23
|
-
|
24
|
-
<pre>
|
25
|
-
git submodule init
|
26
|
-
git submodule update
|
27
|
-
</pre>
|
28
|
-
|
29
|
-
To start the jetty:
|
30
|
-
|
31
|
-
<pre>
|
32
|
-
rake jetty:start
|
33
|
-
</pre>
|
34
|
-
|
35
|
-
Note: the first time you start the jetty, you must use the following command in order to properly configure the jetty:
|
36
|
-
|
37
|
-
<pre>
|
38
|
-
rake hydra:jetty:load
|
39
|
-
</pre>
|
40
|
-
|
41
|
-
|
42
|
-
h3. Testing the gem
|
43
|
-
|
44
|
-
The specs and features for testing the gem within the context of a rails 3 app are all contained within the test_support directory. Once you have
|
45
|
-
installed the test app, you will be able to run the specs/features from within that app via the provided rake tasks.
|
46
|
-
|
47
|
-
A rake task is provided for setting up a rails 3 test app in the tmp/test_app directory. To generate the app, run:
|
48
|
-
|
49
|
-
<pre>
|
50
|
-
rake hyhead:setup_test_app
|
51
|
-
</pre>
|
52
|
-
|
53
|
-
Once you have done this and have a jetty running, you are ready to run the specs and cucumbers:
|
54
|
-
|
55
|
-
<pre>
|
56
|
-
rake hyhead:test
|
57
|
-
</pre>
|
58
|
-
|
59
|
-
This will run the specs and cucumber features from within the test application.
|
60
|
-
|
61
|
-
In order to run a single spec or cucumber feature, use the following from the command line:
|
62
|
-
|
63
|
-
<pre>
|
64
|
-
export RAILS_ROOT="tmp/test_app"
|
65
|
-
rspec test_support/spec/controllers/catalog_controller_spec.rb # path to the spec file you wish to run
|
66
|
-
cucumber test_support/features/mods_asset_show.feature # path to the feature file you wish to run
|
67
|
-
</pre>
|
68
|
-
|
69
|
-
h2. Note about vendor/cache directory
|
70
|
-
|
71
|
-
In order to more quickly install the required gems, the gems have been cached and are stored in the vendor/cache directory. Initially this was done to avoid the
|
72
|
-
excessive amount of time bundler was taking to install all the gems and their dependencies. To get all the requisite gems, simply run:
|
73
|
-
|
74
|
-
<pre>
|
75
|
-
bundle install --local
|
76
|
-
</pre>
|
77
|
-
|
78
|
-
The cached gems also provide a quick means for generating a gemset for the test_app.
|
79
|
-
|
80
|
-
When developing the hydra-head gem, be sure to commit changes to the vendor/cache directory when you update or install a new gem.
|
81
|
-
|
82
|
-
h2. Note about solr and fedora config files
|
83
|
-
|
84
|
-
When you change the solr and fedora config files, you must update them in the generator templates directory (lib/generators/hydra-head) as well as root of the hydra_head code.
|
85
|
-
|