OOP Projektabhängigkeiten: A cycle was detected in the build path of project

[Gaaast1234]

Hallo!

Ich hab da wohl ein Verständnisproblem wenn es ums Thema Projektabhängigkeiten oder Plugin Programmierung geht.
Fakt ist: Ich habe zwei Projekte. Im Grunde ist eines der Projekte eine Art Plugin.
Das eigentliche Projekt greift aber nun auf mein Plugnn zu um sich Werte zu holen, die dann im eigentlichen Projekt an der Oberfläche ausgegeben werden. Wiederum erweitert mein Plugin das eigentliche Projekt und muss somit auch darauf zugreifen.
Nun ist meine Frage, wie gehe ich vor? Ich glaube man kann diese im Titel beschriebene Fehlermeldung abschalten. Aber macht das auch Sinn? Natürlich hätte ich gerne keinen Zyklus, aber kann ich das überhaupt vermeiden? So habe ich ja nun zwangsläufig einen Kreislauf...?

Wäre euch für Ratschläge sehr dankbar.

Gruß

 

[maki]

"gerne keinen Zyklus haben wollen" ist wohl ein Scherz, das ist ein schwerwiegender Designfehler das u.a. einen autom. Build unmöglich macht.

Behalte die Abhängigkeiten deiner Bundles im Auge, Zyklen sind verboten!

Dazu hilft es manchmal, Bundles noch weiter runterzubrechen, gemeinsam genutzte Klassen/Services/Interfaces gehören in (mindestens) ein eigenes Bundle.
Helfen können auch die Eclipse-BuddyPolicy oder DynamicImport-Package, aber runterbechen ist meistens sauberer, falls möglich.

OSGi ist nunmal ein Modulsystem, das Eclipse Plug-In Konzept setzt darauf auf, es ist vollkommen normal dass selbst kleinere Apps aus mehreren Bundles/Plugins besteht, hab keine Angst davor.
OSGi Bundles/Eclipse Plugin bestehen meist nur aus sehr wenigen packages.

 

[Gaaast1234]

Das heißt dann, dass selbst ein OSGi Plugin solche Abhängigkeiten nicht erlaubt und ich dafür sorgen muss, dass, so wie du sagtest, ich gemeinsam genutzte Klassen/Services/Interfaces benötige?
Wenn ich zunächst das Plugin nicht als OSGi Plugin programmieren möchte, sondern einfach Abhängigkeiten über den BuildPath steuere, muss ich dann etwas für die spätere Umsetzung als OSGi Plugin beachten?

 

[maki]

Das heißt dann, dass selbst ein OSGi Plugin solche Abhängigkeiten nicht erlaubt und ich dafür sorgen muss, dass, so wie du sagtest, ich gemeinsam genutzte Klassen/Services/Interfaces benötige?

Gerade ein OSGi Bundle bzw. Eclipse Plugin darf solche Fehler nicht erlauben!
Darum geht es doch beim Dependency Management.

Kennst du das sog. "Whiteboard Pattern"?

Wenn ich zunächst das Plugin nicht als OSGi Plugin programmieren möchte, sondern einfach Abhängigkeiten über den BuildPath steuere, muss ich dann etwas für die spätere Umsetzung als OSGi Plugin beachten?

Wenn du das machst hast du mehr aufwand als wenn du es direkt als OSGi Bundle schreibst
Müsstest zusehen dass die "dreckigen" Stellen bereinigt werden, usw., das kann ganz schön viel Arbeit sein, besser sie gar nicht entstehen zu lassen.

 

[Gaaast1234]

Kennst du das sog. "Whiteboard Pattern"?

Nein, kenne ich nicht, werde es mir aber mal anschauen, danke.

Wenn du das machst hast du mehr aufwand als wenn du es direkt als OSGi Bundle schreibst
Müsstest zusehen dass die "dreckigen" Stellen bereinigt werden, usw., das kann ganz schön viel Arbeit sein, besser sie gar nicht entstehen zu lassen.

Das ist gut zu wissen, aber ich denke ich werde es zunächst mal nicht als OSGi Bundle schreiben, sondern erst den anderen Weg versuchen, dazu habe ich aber noch generelle Fragen...

Mir ist eines nicht ganz klar und leider ist dies ein grundlegendes (Verständnis-)Problem. Ich erklärs mal am Beispiel, welches ich gerade selbst versuche. Ich habe ein größeres Projekt, welches ich mit meinem Plugin erweitern möchte. Um genau zu sein würde ich gerne eine Art Autovervollständigung einbauen.
Nun aber vollgendes: Wenn mein Plugin nun das Projekt kennt, aber nicht anders herum, wann weiß das Projekt dann, wann das Plugin aktiv werden muss? Ich kann es (das Plugin) im BuildPath nicht referenzieren und kann somit auch keine Instanz davon erzeugen, um eine Methode innerhalb dieses Plugins aufzurufen.
Mir ist leider bislang nur der Weg bekannt, dass im Projekt eine Instanz einer Klasse des Plugins erzeugt wird und diese dann im Laufe des Programms aufruft. Schnittstellen sind mir sicherlich bekannt, aber vllt. ist mir die korrekte Verwendung einfach auch noch nicht klar. Prinzipiell stellt das Projekt ja Schnittstellen bereit. Das Plugin kennt diese Schnittstellen und kann sie implementieren. Aber wie merkt das Projekt nun wiederum, dass ein externes Plugin diese Schnittstelle implementiert, ohne ein Instanze einer Klasse dieses Plugins zu erzeugen, da dies ja nicht erlaubt ist??

Wäre euch sehr dankbar für weitere Hilfe!

Grüße

 

[Gaaast1234]

Kann mir keiner mehr weiterhelfen?

@maki
Was meinst du?

 

[Gaaast4567]

Hallo,

ich habe ein ähnliches Problem. Ich muss ein großes Projekt refaktorisieren und habe die folgenden Patterns angewandt:
Replace Conditional with Polymorphism und Replace Type Code with State/Strategy. Für den ersten Teil hat das bereits sehr gut funktioniert, der zweite Teil ist noch ausständig.

Beim zweiten Teil habe ich das Problem, dass ich Projekte so hinzufügen müsste, dass ein Zyklus entsteht. Da das selbstverständlich ncht möglich sein darf und Kopieren von Packages auch keine Alternative ist (Stichwort Code Duplication) suche ich also nach einer Möglichkeit z.B. mit import zu arbeiten (über Projektgrenzen hinweg).

Ich nehme an es gibt so etwas? Wie heißt das bzw. wie macht man das denn?

Danke schon im Vorhinein für die Hilfe.

Grüße

 

[maki]

Lagere gemeinsam genutzte Interfaces/Klassen/etc. in eigene Projekte (Jars) aus, diese werden dann von den Projekten/Jars eingebunden welche sie brauchen.

 

[Gaaast4567]

wow, ihr seid ja echt schnell - danke für die rasche Antwort

Die Idee ist prinzipiell nicht schlecht, allerdings bin ich mir nicht sicher ob das in meinem Fall zulässig ist (ist eine Uni Übung - muss also noch mit der Übungsleitug klären ob ich einfach so munter Projekte erstellen darf). Gibt es noch andere Möglichkeiten? Wie gesagt etwas in Richtung import oder so wäre echt super, weil damit gibts eigentlich die wenigsten Seiteneffekte und auch die geringsten Änderungen

 

[maki]

Das ist genau der Punkt: imports
oder allgemeiner: Abhängigkeiten

Wenn Proj. A das Projekt B referenziert und Projekt B das Projekt A, dann hast du deinen Cycle, das ist schlecht
A -> <- B

Wenn du es aufbrichst und gemeinsam genutzte Klassen/Interfaces in ein Projekt C auslagerst, hast du das Problem gelöst
A -> C <- B

Eine andre Möglichkeit sehe ich nicht, ausser natürlich alles in ein Projekt zu werfen.

 

[SlaterB]

ich weiß nicht, ob bekannt/ vorausgesetzt, aber bevor gar nicht angesprochen wird:
A <- B

A kommuniziert auch mit B, aber nur über allgemeine Observer-/ Listener-Interface,

so wie wie eine Swing-GUI die Listener eines bestimmten Programms aufruft,
ohne dass dessen Quellcode beim Kompilieren (der Java-API) bekannt sein muss