- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
FirstSpirit und Maven
Hallo.
Wir wollen unsere selbstgeschriebenen Firstspirit-Module auf Maven umstellen.
Gibt es ein Repo, wo ich das fs-client.jar mit entsprechend gut gepflegten transitiven Abhรคngigkeiten finde?
- Labels:
-
Developers
- Tags:
- maven
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hi,
kurze antwort - nein
--
andre
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Gibt es denn Plรคne, dies anzubieten?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
mir sind keinerlei plรคne bekannt fuer alle in der wartung befindlichen firstspirit-version sowas anzubieten. es sollte ja kein problem sein ein "eigenes" lokales/zentrales reprository aufzusetzen.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sicher nicht, aber die transitiven Abhรคngigkeiten zu pflegen, die sich ja derzeit scheinbar direkt in dem JAR befinden (...), schon. Schade.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hallo Herr Rรถรler,
Da die Abhรคngigkeit im fs-client.jar enthalten sind, mรผssen diese ja nicht in das Repository.
Oder wollten sie ein fs-client.jar ohne die Abhรคngigkeiten?
Viele Grรผรe
Thorsten Marx
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ich will eigentlich vermeiden, dass Abhรคngigkeiten doppelt in den Classpath geladen werden oder schlimmer: in einer anderen Version in den Classpath geladen werden, denn das kann zu Seiteneffekten fรผhren, die nur schwer reproduzierbar sind. Daher auch die Idee mit Maven, hier kann man die Dependencies besser verwalten.
Meine Idealvorstellung wรคre ein fs-client.jar, dass den FS Code enthรคlt und selbst Abhรคngigkeiten wie slf4j, google gdata, jgraph, apache commons etc. zieht, die ich bei Bedarf auch durch neuere Versionen ersetzen kann.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hallo Herr Rรถรler,
da beim Classloading im FirstSpirit Server meines Wissens benรถtigte Klassen ersteinmal in den Bibliotheken des FirstSpirit Servers gesucht werden (m.E. ein Bug) und erst anschlieรend auf die durch Module bereitsgestellten globalen oder moduleigenen Bibliotheken zurรผckgegriffen wird, lassen sich Redundanzem im Classpath genaugenommen nur dann vermeiden wenn sie auf Bibliotheken aufsetzen der Server bereits mitbringt sofern sie Bibliotheken verwenden die auch der Server verwendet. Bspw. bringt der Server ein commons-io mit, wenn Ihr Modul ein eigenes commons-io mitbringt in einer anderen Version so wird serverseitig bei der Ausfรผhrung Ihres Code die commins-io Bibliothek des Servers verwendet!
Wir verwenden in unseren Projekten ebenfalls Maven und haben ein eigenes Repository aufgesetzt in welches wir regelmรครig die fs-access.jar, fs-webrt.jar etc. deployen. Da die FirstSpirit Bibliotheken m.W. nicht mit Maven gebaut werden bringen diese auch keine Transienten Bibliotheken mit, auf diese Weise werden Sie keine redundanten Bibliotheken bspw. in der Eclipse IDE bekommen.
Die Idee das z.B. die Abhรคngigkeiten des fs-client.jar abรคnderbar sind halte ich fรผr Riskant, wie soll der Hersteller auf diesem Wege fรผr die Funktion der Bibliothek garantieren?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hallo, Herr Holst.
Schaut man mal in die fs-client.jar, stellt man fest, dass nicht nur espirit libraries dort enthalten sind, sondern alle transitiven Abhรคngigkeiten auch, z.B. Google Gdata, Jgraph, Javax Mail, Activation, javax Annotation, apache commons logging/lang, httpclient uvm.
Mal davon abgesehen, dass ich nicht weiร, in welchen Versionen diese vorhanden sind: Bringe ich nun bspw. eine eigene Abhรคngigkeit z.B. apache httpclient mit, wer garantiert mir, dass immer die gleiche Version geladen wird, ob die von mir mitgebrachte oder die aus der fs-client.jar....IMHO kann mir das keiner garantieren, dementsprehend kann dies dazu fรผhren, dass bei einem Start die Lib aus der JAR geladen wird, das andere mal die Lib, die ich mitbringe. Gibt es in diesen Libs nun Unterschiede in Implementierungen o.รค. kann das beim ersten Mal zu unerwรผnschten Verhalten fรผhren, beim zweiten Mal nicht...also ein schwer reproduzierbares Problem.
Streng genommen dรผrfte ich also KEINE der Libs mitbringen, die die fs-client.jar enthรคlt, angefangen beim log4j bis hin zu javax mail.
Es klingt alles ein biรchen konstruiert, nur mรถchte ich dieses Problem nicht wegignorieren, da es durchaus real ist....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hallo Herr Rรถรler,
die fs-client.jar bringt eine Menge transitiver Abhรคngigkeiten mit, das ist korrekt. Ich bin jedoch der Auffassung dass die Implementierung eigener Module unabhรคngig von diesen Bibliotheken erfolgen muss. Das Classloading Verhalten der zugrunde liegenden Plattform (Client oder Server) sollte so ausgerichtet sein, dass die Bibliotheken der Plattform bei der Ausfรผhrung von Code aus Modulen, die ihre eigenen Bibliotheken mitbringen, erst dann verwendet werden wenn die Bibliotken der Module die benรถtigten Klassen nicht enthalten, wenn รผberhaupt. Denn wenn die Bibliotheken der zugrunde liegende Plattform bei der Ausfรผhrun modulspezifischen Codes verwendet werden kann dies, wie von Ihnen beschrieben, zu unerwartetem Verhalten fรผhren was unbedingt zu vermeiden ist, da bin ich ganz bei Ihnen.
Leider funktioniert das Classloading Verhalten nicht so wie ich es erwarten wรผrde, wie ich im vorigem Post bereits am Beispiel der commons-io beschrieben habe, wodurch wir bereits Probleme bei der Ausfรผhrung von Code eines unsere Module bekommen haben. Meiner Meinung nach ist die ein Fehlverhalten des Servers (ob es im Client ebenfalls nicht korrekt funktioniert habe ich noch nicht getestet) zu welchem ich bereits mit eSpirit รผber das Helpdesk Kontakt aufgenommen habe.
Welches Verhalten seitens eSpirit als "korrekt" hinsichtlich des Classloadings angesehen wird ist mir dabei nicht ganz klar. Da jedoch fรผr die Entwicklugn von Modulen keinerlei Informationen รผber die im Server oder Client laufenden Bibliotheken verfรผgabr sind kann "korrekt" meiner Meinung nach eigentlich nur ein von der Plattform unabรคngiges Classloading mit den Bibliotheken der Module sein. Eine Vorgabe der Bibliotheken durch die ausfรผhrende Plattform halte ich ohnehin fรผr fragwรผrdig, es kann ja nicht sein dass man sich bei der Entwicklung von Modulen auf Klassen beschrรคnken muss die aus Bibliotheken der Plattform kommen. Was ist wenn man bspw. Klassen aus einer commons-io in der Version 1.4 benรถtigt, die Plattform jedoch nur ein commons-io in der Version 1.3 beinhaltet?
Wir halten es bei der Entwicklung eigener Module diesem Ansatz folgend ohnehin so das die die fs-client.jar nicht als Bibliothek genutzt wird, lediglich die fs-access.jar sowie die fs-webrt.jar da nur diese Bibliotheken den Stabilittรคtskriterien des Herstellers unterliegen zumal wir vermeiden wollen das bei der Entwicklung Klassen verwendet werden die nicht Teil der Access oder Developer API sind.
Wir hatten tatsรคchlich schon Probleme (ClassNotFoundException und NoSuchMethodException) die durch die angerissene Problematik entstanden sind, daher bin ich auch der Meinung das dies eine ernst zu nehmende Problematik ist und es aktuell ein wenig zum "Glรผcksspiel" wird auf die richtigen Bibliothken zu setzen..

