Was ich vielleicht vergessen habe zu erwähnen, IBM schreibt mit Cics Version 5.x ZWINGEND vor, dass auf dem Cics deployte (schönes Denglisch) Anwendungen mit OSGi gebaut sind.
Wir haben nichts verbockt, wir werden einfach gezwungen uns damit auseinanderzusetzen. Das Problem liegt in der Kombination WebLogic -> Cics, weshalb OSGi noch nicht richtig läuft.
Achja und WebLogic ist ein Applikationsserver von Oracle.
Ja was OSGi dafür kann weiß ich jetzt immer noch nicht…
Ich möchte hier nicht zu sehr ins Detail gehen, weil das definitiv zu sehr offtopic wäre, wo wir uns ja jetzt schon tummeln.
Es hat etwas damit zu tun, dass jedes OSGi-Bundle einen eigenen Classloader besitzt und es im Zusammenhang damit Probleme gab Klassen bundle-übergreifend per Reflection zu laden.
[QUOTE=Shadoka]OSGi ist wirklich ganz nett von der Idee her, problematisch ist da nur die Umgebung der Anwendung, sonst schlägt man sich schnell mit Classloader-Problemen rum. Ich sage nur Oracle WebLogic + IBM CICS = viiiiieeel Spaß 
Dumm nur, dass IBM OSGi ab den neuen Versionen zwingend vorschreibt…[/QUOTE]
Aehmm… das sind OSGi Basics, nicht umsonst nennt man es auch ein „strict classloader environment“, kein Bug/Problem sondern gehoert zu den Grundkonzepten von OSGi.
Wir haben nichts verbockt, wir werden einfach gezwungen uns damit auseinanderzusetzen.
Das klingt ja wirklich nach einer guten und vor allem motivierten Herangehensweise
„Kenne OSGi nicht und habe keine Lust darauf…“ 
Wenn man die Anwendung sauber Strukturiert und sich mit OSGi auskennt gibt es da auch keine Probleme, ja wenn…
Bestes Zitat: „Maven builds are an infinite cycle of despair that will slowly drag you into the deepest, darkest pits of hell (where Maven itself was forged).“
Meiner Meinung nach hat Maven schon einige nette Features, aber es fehlen Möglichkeiten zur einfachen Individualisierung eines Buildprozesses, wie man sie z.B. in einem Ant-Task definieren kann.
Das fehlen von „Moeglichkeiten der Individualisierung“ gehoert zu den Maven Konzepten, Convention over Configuration eben.
Es soll nicht jeder Kreativ werden wenn es um bestimmte Dinge wie Projektestruktur (haengt eng mit Architektur zusammen) und Buildsystem geht, dafuer gibt es ja Konventionen.
Ant mit Ivy versagt ganz schoen wenn man versucht ein sauberes Dependency Management aufzuziehen (SNAPSHOTS? Ha!) , dazu kommt das jeder Ant Build eine einzigartige Schneeflocke ist die viel Arbeit verursacht.
Bei uns kann jemand der sich mit Maven auskennt 60 Projekte auschecken, in der IDE einrichten und bauen, in weniger als 5 Minuten.
Was er dafuer braucht: Maven, eine settings.xml Zugang zum internen Maven und SVN Repo, fertig.
Dann haben wir noch ein ant Projekt, da muss man ca. 2 Tage Doku lesen und konfigurieren um das Ding lokal gebaut zu bekommen.
Von der Einrichtung am CI Server inkl. Sonar Analysen ganz zu schweigen…
[QUOTE=maki]Das klingt ja wirklich nach einer guten und vor allem motivierten Herangehensweise
„Kenne OSGi nicht und habe keine Lust darauf…“ :D[/QUOTE]
Da hast du Recht. Wir waren nicht stoisch nach Seneca und waren/sind ziemlich unzufrieden mit der Gesamtsituation.
Zudem kann ich auch keinesfalls behaupten mich ausreichend mit OSGi auseinandergesetzt zu haben, um mit einem OSGi-Profi diskutieren zu können, ich habe nur meine Erfahrungen aus
der Firma wiedergegeben.
[QUOTE=maki;69506]Das fehlen von „Moeglichkeiten der Individualisierung“ gehoert zu den Maven Konzepten, Convention over Configuration eben.
Es soll nicht jeder Kreativ werden wenn es um bestimmte Dinge wie Projektestruktur (haengt eng mit Architektur zusammen) und Buildsystem geht, dafuer gibt es ja Konventionen.[/QUOTE]
Im Unternehmen wird ein modellgetriebener Ansatz verfolgt, d.h. dass unter anderem auch die Buildskripte generiert werden. Es wurde nicht jeder kreativ, sondern nur wenige bei der Erstellung der Templates 
Durch Nutzen der generierten Buildskripte hat man einen zuverlässigen Standard und keine „einzigartigen Schneeflocken“. (Ich habe mal Artikel von Fowler über ‚Snowflake Server‘ gelesen-wusste gar nicht, dass das ein fester Begriff ist)
Das ist eine ziemlich generelle Aussage, ich weiß ja nicht, wie Softwareentwicklung bei euch abläuft. Wenn jeder tatsächlich alle Freiheiten hat, kann ich mir vorstellen, dass sich Freigeister auch interessante Konstrukte schaffen.
Übrigens ist die Buildzeit um Faktoren gestiegen nach Einführung von Maven und das liegt nicht an inkompetentem Personal
[QUOTE=Shadoka]Da hast du Recht. Wir waren nicht stoisch nach Seneca und waren/sind ziemlich unzufrieden mit der Gesamtsituation.
Zudem kann ich auch keinesfalls behaupten mich ausreichend mit OSGi auseinandergesetzt zu haben, um mit einem OSGi-Profi diskutieren zu können, ich habe nur meine Erfahrungen aus
der Firma wiedergegeben.
[/QUOTE]
Das meine ich gebe nicht irgendwas die Schuld, wenn man es nicht verstanden hat :). Und OSGi lernt mal nicht eben so, wenn man eine hoch dynmaische modulare Anwendung und die Vorteile will, muss man halt paar Sachen beachten. Und über Bundle hinweg Klassen mit Reflection zu laden? Aua ? Dependency Injection? OSGi-Services? usw.
Dafür verwendet ihr hoffentlich EMF und Generation Gap Pattern. Alles zusammen mit OSGi + Maven unschlagbar zur Zeit. Generierten Code nicht einchecken von Maven bauen lassen, Customie Code einfach einchecken.
Die Diskussion ueber den Umgang mit generierten Sourcen findet ihr hier: http://forum.byte-welt.net/threads/10474-Umgang-mit-generierten-Sourcen
Ja, gerade eben. Sieht auf den ersten Blick aus wie Ant für C++. Für QT4 werden die Buildfiles automatisch erstellt (qmake) und für den BlackFin kann man direkt die Projektfiles mittels gmake aufrufen. Aber die Exportfunktion ist zu empfehlen, dann ist weniger Müll auf der Konsole zu finden. Und ob ich nun über add_custom_command einen Befehl aufrufe (z.B. Doxygen/cppcheck) oder über Bash erstmal make und anschließend cppcheck oder so, macht (jetzt nach dem Drüberfliegen) keinen Unterschied.
ant und make sind Buildtools …
cmake qmake und co sind buildgeneratoren … aus der gnu(make) welt das pendant dazu sollte die autoconf toolchain sein.
ziel des buildtools ist es, aus einer steuerdatei ein Project zu bauen → also binaries und ressourcen zu erstellen.
zeil des buildgenerators ist es, die steuerdatei für die die buildtools / projectdateien zu bauen.
Eigentlich ist der Buildgenerator nurn Template mechanismus überhalb der buildtools.
Wegens des Comforts kannst den eigentlichen build meist auch über den Buildgenerator anstossen, aber generell ist das nicht dessen aufgabe, und der delegierts auch nur (ruft make, devenv.exe oder msbuild.exe & co für den build auf)
da make files und Projectdateien für diverse IDE’s mehr oder weniger gut dokumentiert sind, koennt man das auch per hand machen
So nen Buildgenerator vereinfacht aber doch einiges
Für einzelne Projecte ist sowas nicht wirklich sinnvoll …
Für plattformunabhaengigkeit + Continius integration + Vereinheitlichung + Abhaengigkeitsmanagment von mehreren Teilprojecten, Pluginstrukturen usw. auf c/c++ ebene kommst mit nem buildtool + shell nicht mehr hin
Ich versuch mich von dieser seite grad an maven anzunaehern und hab da echt arge verstaendnissprobleme.
Ich denk viel zu make/cmake lastig, so richtig klick beim maven studium hats noch ned gemacht
Ciao …
[QUOTE=HBerger]
Ich versuch mich von dieser seite grad an maven anzunaehern und hab da echt arge verstaendnissprobleme.
Ich denk viel zu make/cmake lastig, so richtig klick beim maven studium hats noch ned gemacht
Ciao …[/QUOTE]
Das wird schon noch Klick machen, braucht aber seine Zeit, gerade wenn man von Ant oder make kommt.
Ich mache z.Z. erste Schritte in Sachen Gradle, und obwohl ich Maven schätze und verstehe, komme ich nur schwer mit Gradle zurecht. Da hilft nur am Ball bleiben.