Symfony: Override plugin-model in other plugin

we are building a new website, which will reuse an existing symfony-software used by another website. I'm moving reusable components into a plugin ("app-plugin"), in order to avoid duplicating code and data. The plugin will be configured as svn-external in the websites' svn repositories.

The existing symfony instance contains overridden doctrine classes (models, forms, form-filters) which are originally defined in other plugins (e.g. sfDoctrineGuardPlugin). The overridden classes can be reused by both symfony-instances, therefore I'm going to move them to the "app-plugin". But this causes problems:

If someone, for instance, runs symfony doctrine:build-forms, the moved files will be re-created by the task inside lib/form/doctrine and will contain empty class-definitions. The reason is very clear to me: How was symfony supposed to know that the "app-plugin" is already defining those form-classes? The only way would be to autoload all classes before executing the task and checking whether classes are already available.

A workaround would be to exclude those classes in the app-plugin's config/autoload.yml. But is there a better way?

Edit

I'm using the 开发者_StackOverflow中文版term "app-plugin" to avoid confusion between normal plugin (e.g. sfGuard) and our plugin which contains shared components.

---

Before:

---

After:

---

What is this "app-plugin" you are talking about ? Normally, all you have to do is leave your overriden classes where they are, and move the code they contain in the parent classes, which are supposed to be in the plugin. And if you want to change the behavior for a particular symfony app, then you may edit these overriden classes.

---

There seems to be no better way than excluding the original model in the app-plugin's config/autoload.yml. Even if you can derive model-classes as shown in the images above you'll get in trouble as soon as you run the build-forms task. I looked through the form-generator's source code which reveals that this isn't possible. Therefore, the only solutions are: avoiding the build-forms task, rewriting the form-generator or, as already stated, using autoload.yml.