Make PaperTrail a Rails engine

[yuki24]

I've read #216 and you might think it is unnecessary, but it does provide some benefits.

Gems like kamianri assume that every AR model is lazily loaded on Rails in development or auto-loaded in production. With this lazy loading mechanism, we can implement some useful features. For example, kaminari allows the user to change the page method name(by default it is .page) to whatever the user wants to call. However, since the PaperTrail::Version class is manually required by the gem, it can't take the advantage of this mechanism. As a result, kaminari fails to define the page method with the right name(see: https://github.com/amatsuda/kaminari/pull/262).

It sounds like it is just a kaminari/paper_trail-only issue, but it also could happen to any other gems. To solve that issue, we can make PaperTraila a Rails engine so Rails will automatically load the PaperTrail::Version class. Could you think about merging this request?

[batter]

Thanks for the Pull Request. Is there any way you could write some automated tests for this demonstrating how the behavior changes as a result of this? Also, the gem is purposely decoupled from Rails (or at least doesn't require rails by default) so that it can be used outside of Rails if the user chooses to do so, so this class would need to go in lib/frameworks/rails/engine.rb or something to that effect I would think. Cheers!

[yuki24]

We can still use PaperTrail::Version if we make the change below in paper_trail.gemspec:

-  s.require_paths = ['lib']
+  s.require_paths = ['lib', 'app/models']

But this will require us to do require 'paper_trail/version' before we actually use it, we can let PaperTrail do it if Rails is not defined, though.

And yes, PeperTrail::Engine could be moved to lib/frameworks/rails/engine.rb.

Speaking of automated tests, we can definitely do it. However, I can't come up with a nice test for PaperTrail::Version. I can add the ability to configure and dynamically change current_user in lib/frameworks/rails.rb to something e.g. current_person by applying this pattern, but I think this is outside of the scope of this pull request.

[batter]

@yuki24 - Sorry for the delayed response. Now that I have time to look at this a little more closely, I think I agree that it makes sense to make the gem an engine when used inside of Rails, however, your PR failed to pass on Travis, and I'm not sure it's a complete implementation. Is there more that needs to be done here to make this work properly? I'm going to try to do some reading on Rails Engine implementations, but I want to make sure this case will cover issues like amatsuda/kaminari#262.

[batter]

Hey, so I just took a crack at cleaning up the groundwork you had done for this. Does this look like it will handle the type of issue from that Kaminari issue report? Here is the commit on a branch