I’m highly interested in getting a working Engines setup running on
Rails 2.0 as soon as possible. I have convinced a customer to use
Engines to slice up a huge Rails app but he wants it to run Rails 2.0
I can’t seem to get it working though at all. Basically I’ve set up a
fresh Rails app and added the Engines::PluginLoader like given in the
ticket above. In environment.rb I added below the boot.rb require line:
And in vendor/plugins/engines/lib/engines/rails_extensions/rails.rb at
the top:
require ‘active_support’
Mongrel will then die with the error:
vendor/rails/railties/lib/initializer.rb:193:in `initialize’: wrong
number of arguments (1 for 2) (ArgumentError)
Not sure what’s wrong here. Looking at the #initialize method of the
Engines::PluginLoader that fails here this very much looks like the #initialize method of the Engines Plugin class.
Can anybody help me out with this? Probably someone has running Rails
2.0 application set up with Engines and can zip me up the whole
application as a starting point?
I’m eager to get something up and running by Wednesday evening because
I want to present it to a customer who wants to slice up a huge Rails
app and Engines seems to be the perfect choice for that. It has to
work with Rails 2.0 though.
Also … I’d be interested in learning if there’s any work in progress
for an official version of Engines for Rails 2.0.
I’ve added a PluginLocator (extending the
Rails::Plugin::FileSystemLocator) instead of a PluginLoader because
that’s the class that is responsible for finding and instantiating
plugins in Rails 2.0
Also I’ve changed the Engines Plugin class to extend the Rails::Plugin
class.
I’ve tried this with Gwyn Morfey’s Macaque engine and it exports the
migrations with script/generate plugin_migration. Also Mongrel starts
up and I can access the MacaqueController with the appropriate views
etc.
I’m still super-curious about what’s necessary to get an official
Engines version for Rails 2.0 going.
Thanks!
Am 20.11.2007 um 14:15 schrieb Sven F.:
I can’t seem to get it working though at all. Basically I’ve set up a
require ‘active_support’
Can anybody help me out with this? Probably someone has running Rails
Thanks for these patches - I’m definitely keen to get a Rails 2.0
compatible version of the engines plugin released as soon as possible.
Until recently I was holding out for some changes to the internal
mechanisms used by Rails to load plugins
(http://dev.rubyonrails.org/changeset/8115), but now that those
changes have been accepted I hope to fix up the engines plugin soon.
Since Rails’ own “native” plugin loading mechanism has now caught up
with some of the enhancements that the engines plugin used to provide
(a proper plugin model, loading all remaining plugins with :all, etc)
I’m keen to trim down the changes that the engines plugin makes so
that the plugin stays as lightweight as possible.
If you’re keen to contribute, any investigations as to which parts of
the existing codebase (along with your Pastie’d patches) would be
greatly appreciated!
Basically I’d like to start refactoring from my patch and successively
remove duplicate functionality.
I’m not sure if it makes sense to partition this up (you asked for
investigations as to which parts of the codebase I’d want to touch).
As far as I can see there’s:
the Engines’ plugin class could probably be replaced by a module
that would be mixed into the Rails::Plugin class
some of the Engine module could probably moved to
Rails::Plugin::Loader or to a Engine::PluginLoader that extends from
the latter
a dedicated Engine::PluginLocator might be superflous then because
the Rails::Plugin class would be used and Rails::Plugin::Loader seems
to keep track of the plugin instances (is it accessible though?)
Engines::RailsExtensions::RailsInitializer could be removed (it
already is in my patch)
I’ve also looked for test suites in the repository. There seem to be
several applications for testing different Rails versions. The “rails
edge” application doesn’t seem to have any engines installed, the
tests seem to rely on them though (“alpha_engine” etc.). Am I missing
something obvious?
Thanks for these patches - I’m definitely keen to get a Rails 2.0
compatible version of the engines plugin released as soon as possible.
This sentence just lifted a ton of weight off my mind
Until recently I was holding out for some changes to the internal
mechanisms used by Rails to load plugins
(http://dev.rubyonrails.org/changeset/8115), but now that those
changes have been accepted I hope to fix up the engines plugin soon.
This stuff is already in Rails 2.0 RC1, isn’t it? Because in http://dev.rubyonrails.org/ticket/9795
you say that you’ve added a class Rails::Plugin and I’ve already
seen this one (and even extended it in that patch). Ok, I think I’ll
go and read that stuff up.
Since Rails’ own “native” plugin loading mechanism has now caught up
with some of the enhancements that the engines plugin used to provide
(a proper plugin model, loading all remaining plugins with :all, etc)
I’m keen to trim down the changes that the engines plugin makes so
that the plugin stays as lightweight as possible.
Yes, I already wanted to ask about that. Looks like quite some stuff
could be dropped from Engines.
If you’re keen to contribute, any investigations as to which parts of
the existing codebase (along with your Pastie’d patches) would be
greatly appreciated!
I haven’t used Engines so far and don’t even know all of its features
That said, I would be happy to contribute as I’m both personally and
professionally interested in this approach.
I guess I’ll just spend some more time on reading the codebase and
then report back.
That’s one of the most exciting features of 2.0 for me, as virtually
every engine I’ve written has one (or more!) .js files. I didn’t see
any code (or tests) looking at that feature yet. But I’m not much of an
engines core hacker yet…
The first goal is to get Rails Engines working on Rails 2.0 with the
functionality it already has on Rails 1.2. This requires some quite
extensive refactoring as Rails 2.0 has adopted some of the internal
means for plugin loading etc. that Rails Engines provided for Rails
1.2. (Rails Engines for Rails 2.0 will build on this infrastructure
and therefor will be much more lightweight.)
That said, I’d also love to see that feature in Rails Engines
Am 07.12.2007 um 22:11 schrieb Rob M.:
yes, this thread has been continued on the engine-developers list
That said, all the other tests are passing, i.e. the basic
Am 07.12.2007 um 20:29 schrieb Tony A.:
the Engines’ plugin class could probably be replaced by a module
several applications for testing different Rails versions. The
Engine-Users mailing list
Also, the ActionMailer seems to have changed in Rails 2.0 and this
part of Engines is currently just deactivated.
That said, all the other tests are passing, i.e. the basic
functionality (like model/view/controller loading, routes, migrations
etc.) already seems to work. (I also have it being used at a client of
mine for test purposes and there haven’t been any problems with the
basic stuff.)
If you want to get involved with helping here, … I guess that’s
appreciated as everybody seems to be pretty busy these days.
Am 07.12.2007 um 20:29 schrieb Tony A.:
Rails::Plugin::Loader or to a Engine::PluginLoader that extends from
Engines::RailsExtensions::ActiveRecord
Checkout the toolbawks_packer plugin I wrote up. It allows you to do
just
that bug even better. Planning on moving more towards a bundle_fu
approach
with a block wrapper, but right now it works awesome for me. Beta
software
so far, but will do the trick never the less
Also, I have dropped in bundle_fu in existing apps as well, and it works
pretty decently as well.
With that said, we don’t really need it in Engines directly per-say, as
additional options are available, but nice if it was there. Although
Rails
2.0 doesn’t really do the job that well, or at least as well as the
toolbawks_packer and bundle_fu plugins do.
Nathaniel.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
