ich bekomm langsam echt Probleme mit Eclipse (STS) wenn ich mein Programm im Eclipse starte, alles super. Baue ich das jar und rufe es im Terminal auf, kommt Fehler siehe unten beim ausführen. Die betreffenden Klassen wurden NICHT angefasst heute!!! Heute Mittag lief es wie auch immer!
Description:
Field taxClassRepository in com.tenancy.controller.TaxClassController required a bean named ‘tenantEntityManagerFactory’ that could not be found.
- Bean method ‘entityManagerFactory’ in ‘TenantDatabaseConfig’ not loaded because @ConditionalOnBean (names: datasourceBasedMultitenantConnectionProvider; SearchStrategy: all) did not find any beans named datasourceBasedMultitenantConnectionProvider
Die entsprechenden Beans sind da, wie gesagt Mittag klappt, das aktuelle Bulit nicht. Diese Probleme hab ich permanent! Es kann doch nicht sein, dass sowas von jetzt auf gleich nicht mehr geht, die Klassen wurden 1 Woche nicht angefasst. Ich hoffe mir kann jemand helfen.
Edit: Jetzt hab ich Eclipse geschlossen und neu geöffnet, clean install und es geht. Das kann doch nicht sein…Liegt das an Eclipse? Sollte ich mich nach einer anderen IDE umsehen?
IDEs können manchmal Maven-Builds in die Quere kommen, das kann aber mit jeder IDE passieren.
Man sollte einfach immer den Maven-Build als Referenz nutzen, im Idealfall nicht auf dem Entwickler-Rechner, sondern nem extra Build-Server und mit vorherigem Clean gebaut. Wenn es dabei Probleme gibt, liegt’s am Projekt selbst.
darin sind meine Microservices. Wenn ich nun Jenkins konfiguriere, geb ich da die URL mit.git an, aber er “geht nicht in die Unterordner”. Muss ich für jeden Service (eigene pom usw) ein eigenes Repo in Bitbucket anlegen?
Ja, Jenkins ist ganz gut. Alternativ Bitbucket Pipelines, wenn du Bitbucket nutzt.
Es würde reichen, den Job im Jenkins passend zu konfigurieren.
Unterschiedliche Repos können es zT einfacher machen, unabhängig voneinander sind die Services ja schon?
Jenkins wäre schon gut. Weiß du was ich konfigurieren muss, damit Jenkins in die Ordner schaut? Hab als Repo die URL mit .git angegeben aber da kann er nix finden, logisch. Ich finde aber nicht wo ich da was einstellen könnte
Wie hast du Jenkins denn überhaupt konfiguriert?
Je nach Art des Jobs gibts ja zig verschiedene Möglichkeiten, und afaik muss man bei allen irgendwie den Pfad angeben…
Hab jetzt Bamboo im Einsatz, das arbeitet mit den anderen Atlassian Tools zusammen, aber was ich nach wie vor noch nicht gefunden habe, ich wo ich den Pfad angebe. Der erste Service aus dem Repo wurde gebaut und läuft, nur die anderen Services wurde nicht gebaut
Und der baut ohne jede Konfiguration einfach ein Unterprojekt?
Wenn alle auf einmal Gebaut werden sollen kann wie gesagt eine Parent-Pom für die Services helfen, oder halt eigene Repos, macht aber manche Dinge auch komplizierter.
Repos konfiguriert man in Bamboo in den sog. „Linked Repositories“, man muss per Repo auch einen Branch (normalerweise master) angeben, Git Repo + Branch = Linked Repo
Den Pfad konfigurierst du per „Working Directory“ in den einzelnen Tasks.
Bamboo nutzt ein etwas komplexes Modell IMHO
Bamboo → Project → Plan → Stage → Job → Task
Das macht aber fuer MS wenig Sinn IMHO
Sind ja dann wieder gekoppelt…
Fuer MS auf jedenfall.
Wozu alles in „unabhaengige“ MS aufbrechen nur um dann wieder alles in ein „monorepo“ zu werfen?
Maki, danke! Er baut nun mit bamboo…aber er baut und baut und baut es hört nicht auf.
Mit fällt ein, ich habe ein .jar (ich nenn es mal Pojo-Vorlagen) darin sind Objekte, die von allen Services benötigt werden.
Damit nicht jeder Service sein eigenes „Auto“ hat. Wenn ich dem „Auto“ nämlich ein neues Attribut „Farbe“ setze, mache ich es einmal in „Pojo-Vorlage“ und alle Services haben das Update für die Farbe und können es nutzen. dieses ist dann ein normales .jar. das wird auch ein Problem sein baum bauen mit Bamboo. Aber es gibt da was mit „vorgelagerten Projekten“ das klingt dahingehend irgendwie sinnvoll.
Ganz ehrlich, am einfachsten ist es, wenn du alles in eine Stage wirfst, dann einen einzigen Job erstellst, und alles in Tasks nacheinander abarbeitest, das spart viel Konfiguration (artifakte), wird aber eben alles sequentiell gebaut.
Persoenlich finde ich Jenkins besser weil einfacher
Ich erinnere mich an die Diskussion hier, hoffe du erinnert dich dass das die Entkoppelung von MS ad absurdum fuehrt wenn MS Domaenen Code teilen
Aber wenn dir das alles wurscht ist, kannst du es gleich in ein Maven Projekt klatschen in dem alle Services ein Parent haben und dieser Parent die module pro Service festlegt.
Hast dann einen monolitischen Build, aber den scheinst du sowieso zu haben
Danke für deine Erläuterung, das Builtproblem muss ein anderes sein, wenn ich auf dem Server in das Verzeichnis gehe, wo Bamboo alles ablegt und manuell mit mvn clean install oder so aufrufe, bleibt es beim download der Dependencies hängen. (Die URL zum .jar kann ich aber abrufen, da kommt auch was )
Bezgl.der Kopplung, ist korrekt, aber ich habe da wirklich wenig Lust, mein „Auto“ in sämtlichen Services anzupassen. So mach ich es einmal. Solange es gut geht sehe ich da kein Problem Diese ganze Built Geschichte macht mir zur Zeit mehr Sorgen.
Das mit der Stage werde ich so machen, dann muss man nicht so viele Bulit (Plans?)/Projekte anlegen. Wird für meine Zwecke wohl wirklich ausreichen.
Werde parallel nochmal Jenkins testen, ob es das gleiche Problem hat wie Bamboo
Spaetestens an dieser Stelle solltest du die settings.xml, build log und wohl die POMs herzeigen falls du Hilfestellung erwartest.
„Problem“ ist es nur insofern dass das eben keine MicroServices sind die du da baust, ist eine Frage des Designs und ob es nicht besser waere ein anderes, einfacheres und passenderes zu nehmen, nicht ob es „funzt“.
Ein Project, ein Plan, eine Stage, ein Job und mehrere Tasks.
Einfacher IMHO schon, googeln laesst sich auch einfacher IMHO nach Jenkins Problemen, aber ob es dein Maven konfig Problem magisch loest? Eher nicht
Dann baue ich Nicoservices Sehe darin für mich wirklich keinen Vorteil, wenn jeder Server die Objekte hat, dass widerspricht irgendwie dem „Code wieder verwenden“. Wenn man je Service ein Team hat, ist das sicherlich was gutes, dann ist es total unabhängig.
Habe nun einen Fehler bekommen Could not transfer artifact com.fasterxml.woodstox:woodstox-core:jar:5.0.3 from/to central (https://repo.maven.apache.org/maven2): GET request of: com/fasterxml/woodstox/woodstox-core/5.0.3/woodstox-core-5.0.3.jar from central failed: Read timed out -> [Help 1]
Scheint als wäre da eine Dependency nicht online oder?
Es geht darum, dass es dem einen Service egal ist welche Farbe das Auto hat.
Das Konzept hinter MS ist folgendes. Dem kann man dann zwar mehr Informationen zuschicken und der filtert sich nur die relevanten raus oder leitet die zusätzlichen Informationen einfach mit weiter.
TÜV zum Beispiel ist die Farbe egal, trotzdem erwartet man, dass nach der Hauptuntersuchung das Auto nicht default Weiss lackiert ist.
Und nur weil sich ein Attribut ändert, das irrelevant für einen Service ist, sollte dieser nicht unbedingt neu deployed werden müssen.
es hört nicht auf.
Diese ganze Built Geschichte macht mir zur Zeit mehr Sorgen.
Sehe darin für mich wirklich keinen Vorteil, wenn jeder Server die Objekte hat, dass widerspricht irgendwie dem „Code wieder verwenden“. Wenn man je Service ein Team hat, ist das sicherlich was gutes, dann ist es total unabhängig.