¿Cómo se maneja el código compartido entre varias aplicaciones SF2?

Digamos que tengo una aplicación SF2 estructurada compleja compuesta de varios packages como CoreBundle, ApiMobileBundle, ApiPartnerBundle, WebsiteOneBundle, WebsiteTwoBundle, Backoffice1Bundle, Backoffice2Bundle, SearchBundle, UserBundle, LogBundle y más …

Hasta ahora, todo fue bien con la aplicación que está siendo versionada en un único repository de GIT. Pero hoy, queremos crear otra aplicación que podría beneficiarse de algunos de los packages de la aplicación principal. Tenga en count que las aplicaciones resultantes no se implementarán en los mismos serveres.

En pocas palabras, queremos compartir varios packages dentro de varias aplicaciones SF2. ¿Cuáles son tus recomendaciones?

Editar

Estoy haciendo esta pregunta porque uno de los desarrolladores con los que estoy trabajando dice que es pura herejía y no en la filosofía de SF2 (con respecto al esqueleto de la aplicación, la administración de proveedores, los files de configuration, etc.). Sostiene que el mejor enfoque es mantener todo en la misma aplicación y que desplegar fonts innecesarias no es un problema …

Su mejor opción sería extraer los packages del proyecto y almacenarlos en sus propios repositorys git.

Luego, en su file composer.json , agréguelos como dependencies a ambos proyectos.

Por supuesto, eso también dependerá de que su package esté desacoplado de la aplicación, pero ese es un factor de layout y otra pregunta en set.

Espero que ayude.

Podría tener problemas si tiene entidades de Doctrine que están relacionadas entre los packages. Si decide utilizar un package, cuya entidad está relacionada con otro package no utilizado, tendrá problemas con Doctrine, que se explican aquí . Es por eso que es una buena idea usar interfaces para relaciones entre entidades y ResolveTargetEntityListener. (Es decir, si usa Doctrine).

Creo que tengo una solución bastante simple para el problema de la entidad faltante que planeo publicar en el enlace anterior en los próximos días, a primera hora cuando tenga time para implementarlo, probarlo y publicarlo.

La idea es básicamente mantener todos los packages de forma autónoma como sea posible. No guarde nada en su package principal a less que lo comparta con varios packages o si es de sum importancia que su proyecto en general funcione. Pero el mayor problema que he encontrado hasta ahora son esas malditas entidades.