Rails (3) Engines and Plugins - How to mix application and vendor code?

I'm trying to create several large applications that share 60-80 percent of their functionality. I'd like to find some way to abstract the common functionality into a gem, plugin, or engine which I can then deploy as many times as needed for each application. The catch is each app will definitely need that 20% extra functionality and it may include changes or enhancements to existing functionality found in the core. This includes changes to views and layouts, controllers, models, migrations, tests, etc. I also anticipate that through the development of these applications bugfixes/new features will be added to the core, and it'd be great if all the apps built on top of this core could benefit from them.

It's been suggested to me to use Engines, but I've encountered a number of problems.

First, there doesn't seem to be any way to reopen classes in the application space as far as I can tell. If you define a model in the engine's app folder and not in the applications app folder, Rails will find the engine model and load it and everything will good. If you define it in both folders, it will find the definition in the application's app folder and not look anywhere else, so the engine code never gets loaded. This means I can't reopen my engine's classes to modify them, which is a really big issue. My solution to this is to explicitly require the engine space file from inside the application space file and then subclass the classes defined by the engine in the application space file. This is far from optimal because a) it sucks having to require all those files manually, b) the automatic file reloading across requests seems to be broken, c) the application code is spread across many locations and I find it harder to navigate and debug, and d) views can't be "required" and then partially overridden or anything like that.

I'm also unsure of how things like tests will play out. I've been writing all my tests in the application space for now but the tests that test the core should go into it no? Should I just test overridden or new functionality in the app space? How can I have my test suite run the tests from the engine at the same time?

Migrations are crappy too, how can I manage changes to schema that the application needs on top of those made by the core? Do I wrangle one of the file copy solutions and move core migrations into the app migrations folder? I guess the timestamps would prevent conflicts and I would just have to ensure the application's migrations which change the schema to reflect that app's specific needs are run after the core migrations.

Any tips or help or suggestions? I'm using Rails 3 and Railtie::Engine right now, and I'm not that far in so I could still change everything if need be. I also saw this (http://github.com/pivotal/desert) which seems to mitigate a lot of these issues but is a little outdated and far from Rails 3 friendly.

sair do grupo

queria um nacional