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