ios - test - La clase X se implementa en<framework> y<application> se utilizará una de las dos, que es indefinida

moose test ranger

Question

Recibo esta advertencia:

Class X is implemented in both <framework> and <application> one of the two will be used, which one is undefined

Esta advertencia se cubre bastante en la web, pero no he encontrado nada que responda al problema específico que estoy teniendo.

Guión

Creé MyFramework y MyApplication (como una aplicación de prueba / demostración para MyFramework).

MyFramework utiliza un CocoaPod (al que me referiré como CoolPod), que también quiero usar en MyApplication (y es razonable suponer que un consumidor de MyFramework también lo haría).

Necesito poder distribuir MyFramework como .framework (para fuente cerrada). Sin embargo, esto significa que MyFramework incrusta CoolPod en su biblioteca compilada.

Ahora, cuando importo MyFramework y CoolPod en MyApplication, aparece este conflicto (dando como resultado la advertencia que se muestra arriba) ya que las clases de CoolPod ya están incluidas en la biblioteca de MyFramework (ya que CoolPod está incrustado).

Entonces tenemos esta estructura:

CoolPod -> MyFramework /
MyApplication
CoolPod /

Pregunta

¿Cómo evito este conflicto?

• ¿Hay alguna manera de que MyApplication proporcione CoolPod a MyFramework?
• ¿Tengo que pasar los encabezados de CoolPod a través de MyFramework?

He pensado en incluir los encabezados de CoolPod (pero no su lib) en MyApplication, sin embargo, esto parece demasiado complejo para lo que debería ser un caso simple.

Cualquier ayuda es muy apreciada, esto realmente me está bloqueando en este momento.

Gracias,

Índigo

Answer 1

¡Una solución es activar use_frameworks! en el Podfile del marco. Entonces aún podría compilar su marco de trabajo e insertar su marco en la aplicación de destino. Los mensajes de advertencia desaparecerán (es simplemente porque los pods del marco se cumplen en otro marco, pero no los inserta en su aplicación de destino. Entonces su aplicación se referirá al binario propio).

Pero esta no es una buena solución por dos razones: 1. Debe asegurarse de que la aplicación de destino incluya los pod necesarios que necesita el marco. 2. La aplicación puede usar diferentes versiones de pod para el marco. Si el marco y la aplicación hacen referencia al mismo binario de pod, podría provocar un bloqueo.

Dudo que haya una buena solución para este problema.

Answer 2

Mi solución fue tomar el código fuente de la vaina de cacao y crear un marco Cocoa Touch para ello. Luego vinculé el framework a mi api y a mi aplicación de prueba. Esto no es genial, pero es todo lo que pude hacer rápidamente. Creo que Cocoapods está trabajando en marcos de apoyo, por lo que esta solución puede quedar obsoleta lo suficientemente pronto.

Mi empresa también usa gradle para dependencias (java) y compila scripting. Así que creé una tarea de compilación groovy / gradle que construye mi framework y mis frameworks de soporte (frameworks cocoapod) y crea un framework universal a partir de ellos. Luego comprime todos los marcos. Esto significa que puedo distribuir un zip con todos los requisitos. Obviamente, esta no es la mejor manera de distribuir (vamos a pasar a la distribución a través de Cocoapods con dependencias en nuestros marcos de código cerrado), pero es rápida de configurar.

Answer 3

Para bibliotecas estáticas de código cerrado, recomendamos cocoapods-packager . Aunque no estoy seguro si es soporte para frameworks.

Answer 4

Si desea una solución rápida, simplemente agregue su proyecto MyFramework como un subproyecto al proyecto MyApplication. Todavía puede utilizar los módulos de cacao tanto para su framework como para la aplicación de prueba (pero incluya su lib "común" con pods solo para el proyecto de framework)