Klasse X ist implementiert in beiden <framework> und <Applikation> einer der beiden wird verwendet, welches nicht definiert ist

Bin ich immer diese Warnung:

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

Diese Warnung ist ziemlich bedeckt, ein bisschen über das web, aber ich habe nicht gefunden was als Antwort auf die spezifische problem, das ich habe.

Szenario

Habe ich gebaut MyFramework und MyApplication (als test/demo-Anwendung für MyFramework).

MyFramework verwendet eine CocoaPod (die ich zu beziehen, wie CoolPod), die ich auch verwenden möchten, in MyApplication (und es ist davon auszugehen Verbraucher MyFramework würde auch).

Ich muss in der Lage sein zu verteilen MyFramework als .Rahmen (für closed-source). Dies bedeutet jedoch, dass MyFramework bettet CoolPod in seiner kompilierte Bibliothek.

Wenn ich jetzt importieren MyFramework und CoolPod in MyApplication bekomme ich diesen Konflikt (die Ausgabe der Warnung oben gezeigt) als CoolPod s-Klassen sind bereits im Preis enthalten MyFramework Bibliothek (als CoolPod eingebettet ist).

Also wir haben diese Struktur:

CoolPod -> MyFramework \
                        MyApplication
               CoolPod /

Frage

Wie kann ich vermeiden, dass dieser Konflikt?

  • Gibt es eine Möglichkeit, meine MyApplication bieten CoolPod zu MyFramework?
  • Muss ich pipe CoolPod die Header durch MyFramework?

Ich nachgedacht habe, einschließlich CoolPod die Header (nicht aber die lib) in MyApplication", aber es scheint zu Komplex für das, was sollte ein einfacher Fall.

Jede Hilfe wird sehr geschätzt, das ist wirklich blockiert mich jetzt.

Dank,

Indigo

  • Ich habe ein ähnliches Problem, hast du eine Lösung finden?
  • Ähnliches Problem, aber mit unit-tests, wird hier diskutiert: stackoverflow.com/questions/6149673/...
  • Verwunderlich ist das nicht eine wirklich gemeinsame Muster? Nicht-Entwickler erstellen zu können, DAGs der Zusammenstellung Einheiten, ohne sich sorgen, dass es gonna be Kollisionen?!
  • Hi @Zenton. Neben der akzeptierten Antwort, hast du es geschafft, zu lösen dieses Problem mit einer anderen Lösung? Ich stehe vor dem gleichen Problem, ich würde schätzen Ihre Beratung.
InformationsquelleAutor Zenton | 2015-01-01
  1. 2

    Für closed-source-statische Bibliotheken empfehlen wir cocoapods-packager. Ich bin nicht sicher, es ist Unterstützung für die frameworks obwohl.

    InformationsquelleAutor orta
  2. 2

    Meine Lösung war es, den source code aus dem Kakao-pod und erstellen Sie eine Cocoa-Touch-Framework für Sie. Dann habe ich verlinkt Rahmen meiner api und zu meiner test-app.
    Das ist nicht toll, aber es ist alles, was ich tun konnte, schnell. Ich glaube, dass Cocoapods ist die Arbeit auf der Unterstützung von frameworks, so kann diese Lösung überholt bald genug.

    Meine Firma auch verwendet gradle für Abhängigkeiten (java) und build-scripting. So habe ich eine groovy/gradle-build-task baut, dass mein Rahmen und meine unterstützende frameworks (cocoapod frameworks) und schafft ein universelles framework von Ihnen. Dann ist es Reißverschlüsse alle frameworks. Dies bedeutet, ich kann verteilen Sie ein zip mit allen Anforderungen. Dies ist offensichtlich nicht die schönste Art und Weise zu verteilen (wir bewegen werden, um die Verteilung durch Cocoapods mit Abhängigkeiten, die auf unsere closed-source-frameworks), aber es ist schnell eingerichtet.

    InformationsquelleAutor Zenton
  3. 1

    Einer Lösung ist, um auf use_frameworks! im Rahmen der Podfile. Man dann noch machen könnte Ihr framework kompiliert, und einbetten der Rahmen in der Ziel-app. Die Warnmeldungen verschwinden wird (Es ist einfach, weil framework-pods sind einzuhalten, um einen anderen Rahmen, aber nicht einbetten dieses in der Ziel-app. Dann die app beziehen sich auf die binären der eigenen.)

    Aber das ist keine gute Lösung, aus zwei Gründen:
    1. Sie müssen sicherstellen, dass die Ziel-app die notwendigen Hülsen, die das framework braucht.
    2. Die app möglicherweise verwenden verschiedene pod-version auf den Rahmen. Wenn beide framework und app beziehen sich auf das gleiche pod mit binären, konnte es zum Absturz bringen.

    Bezweifle ich, es ist eine gute Lösung für dieses Problem.

    InformationsquelleAutor syshen
  4. 1

    Wenn Sie wollen eine schnelle Lösung - fügen Sie einfach Ihre MyFramework Projekt als ein Teilprojekt von "MyApplication" - Projekt. Dennoch kann man die kakaofrüchte, die beide für Ihre Rahmen-und test-Anwendung (aber Ihre "gemeinsame" lib mit Hülsen nur für framework-Projekt)

    • Ich war nicht in der Lage zu machen, dieser Ansatz funktioniert - die app den Gegner nicht zu verknüpfen, mit "Symbol(s) not found for arm64-Architektur" für alle Klassen definiert, die in den Hülsen enthalten nur in dem Rahmen. Irgendwelche Ideen?
    • Dieser arbeitete für mich. Ich musste einfach löschen Sie meine Daten abgeleitet, um es zu arbeiten
    InformationsquelleAutor Robert Fogash
  5. 0

    Können Sie erstellen, Podspec für Ihre MyFramework mit CoolPod als Abhängigkeit.

    Ihre MyFramework.podspec wird etwa so Aussehen:

    Pod::Spec.new do |spec|
  spec.name          = 'TestFW'
  spec.version       = '1.0.0'
  spec.license       = { :type => 'BSD' }
  spec.homepage      = 'https://github.com/user/TestFW'
  spec.authors       = { 'Auther Name' => '[email protected]' }
  spec.summary       = 'Testing FW Pod with Test App'
  spec.source        = { :git => 'https://github.com/user/TestFW.git' }
  spec.module_name   = 'TestFW'
  spec.ios.source_files   = 'TestFW/*.swift'

  spec.dependency 'CoolPod'
end

    Und Ihre MyApplication's podfile wird in etwa so Aussehen:

    target 'TestApp' do
  use_frameworks!

  pod 'CoolPod'
  pod 'TestFW'
end
    InformationsquelleAutor Shahrukh Alam
Schreibe einen Kommentar