Maven Verständniss Grundlagen

Java-Forum Deployment
1

Also ich arbeit mich „nebenher“ in Java ein, und bin quasi über maven gestolpert ^^
Ich komme aus der c++ welt, unsere SW wird rein ueber subversion und cmake „verwaltet“.

Bei maven hab ich aber noch leichte Verständnissschwierigkeiten :slight_smile:

WIe setzt man projecte generell auf … also nicht maven archtype… create und so, das liest man im tutorial, sondern wie verwaltet man generell ?
Wenn ich richtig verstanden habe, kann man ueber dependencies + subversion plugins das so aufestzen, das maven den code in abhaengigkeit von einer angegebenen Version ausm svn repo holen kann.

d.h. maven kann meine versionen verwalten ?
also wenn mehrere Leute an einem Project arbeiten sollen …
Dann setzt einer das Project auf,
checkt sourcen etc ein, passt die pom.xml an.
die anderen brauchen dann nur die pom.xml ?
mit der koennen sie sich alle versionen (in dem falle vielleicht nur die initiale) auf ihrerm rechner auschecken und modifizieren ?

Wie wird dann die pom.xml deployed ?
Wenn ich mein project aufm mehrere rechner bearbeiten will … wird da nur die pom.xml ausgetauscht ?
Klar die svn sourcen muessen ueber die selben repository URLs erreichbar sein …
Wie definiert man lokale gegebenheiten … beispielsweisse pfade zu nem Java container für testlauf etc ???

das maven "repository " ist ja erst mal nur local (.m2e)
muss/sollte man nen dann gloables maven repo aufsetzen ?
öffentliche repos wöllt ich nicht nutzen … mein svn repo iss ja z.b. auch ned öffentlich ^^

Ciao …

2

ein maven project besteht ja aus sourcen/resourcen und dependencies. Sourcen und resourcen (also auch pom.xml) kommen ins subversion und jeder der entwickelt checkt sich das projekt dort aus.

Die pom ist ja nur die konfiguration fuer das projekt, beinhaltet aber nicht die java sourcen.

Wenn ihr nicht das maven repository selbst als globales nutzen koennt/wollt, so muesst ihr ein lokal-globales aufsetzen (zb Nexus oder artifactory).

Maven checkt dann ob eine benoetigte Dependency lokal (also lokal-lokal) vorhanden ist, wenn nicht wird sie vom globalen runtergeladen

3

Wenn ich richtig verstanden habe, kann man ueber dependencies + subversion plugins das so aufestzen, das maven den code in abhaengigkeit von einer angegebenen Version ausm svn repo holen kann.

Nein, Maven managed Depdebncies auf ebene von „Artifakten“, also nicht in Quellcodeform sondern in kompilieter Form, vereinfacht ausgedrueckt.
Diese Artifakte liegen in Maven Repositories (lokale, zentrale, Firmeneigene, usw.)
D.h. man hat Quellcode Repos fuer Quellcode, und Artifakt Repos (Nexus, Artifactory, etc.) fuer Artifakte.

d.h. maven kann meine versionen verwalten ?

Ja.

die anderen brauchen dann nur die pom.xml ?

Die POM enthaelt Meta INfomationen, wie zB. den Pfad zu den Quellen in einem SVN oder Git Repo.
Aber auch die Abhaengigkeiten (zu artifakten eines anderen Projektes) des Projektes.
Dazu noch Plugins und deren Konfiguration.

Wie wird dann die pom.xml deployed ?

So wie alle anderen Arifakte (jar, javadoc, etc. pp.) auch.
Ein mvn install installiert sie ins lokale Repo (zB. als SNAPSHOT), andere Befehle und Plugin koennen diese Artifakte in ein Firmenrepo deplozen, meist bei dem Release.
Dafuer nimmt man normaleweise einen CI Server wie Jenkins.

Wenn ich mein project aufm mehrere rechner bearbeiten will … wird da nur die pom.xml ausgetauscht ?

Noe, wozu auch?
Idealerweise kann jeder ein Maven Projekt auschecken und sofort bauen ohne den QUellcode (POM, Sourcen etc. pp.) anzupassen.
Loakel Einstellungen kann man in der setttings.xml verwalten.

muss/sollte man nen dann gloables maven repo aufsetzen ?

Wenn man es ernst meint mit Maven dann muss man das.

öffentliche repos wöllt ich nicht nutzen … mein svn repo iss ja z.b. auch ned öffentlich ^^

Du musst oeffentliche repos nutzen um an Artifakte zu kommen, das geht nicht anders.
Aber deine Firmeninterne Artifakte solltest du wohl nicht dort deplyen, ausser deine Firma macht in OSS.

Empfehle dir die Umfangreiche Doku zu lesen und viel zu ueben, Maven hat eine sehr hohe Lernkurve, ohne Doku und Ueben wird das nix.

4

Sourcen und resourcen (also auch pom.xml) kommen ins subversion und jeder der entwickelt checkt sich das projekt dort aus.

Ahh ok, das hatte ich nicht geschnallt …
das svn plugin ist dann eigentlich nur fuer externe Abhaengigkeiten.

Du musst oeffentliche repos nutzen um an Artifakte zu kommen, das geht nicht anders.

Ja falsch ausgedrueckt, meinerseits.
Lesen auf öffentliche Repos ist ok, für mich zumindest.
Projectdaten schreiben in öffentliche repos eben nicht.
Aber wenn die pom.xml im scm liegt, isses nicht das problem.

Wir haben Entwickler, die bekommen kein Inet zugang(Proxy Zulassung, ja sowas gibts). Für die muss man dann die externen abhaengigkeiten in ein firmen-repo überführen, fuer sowas sind die da oder ?

Empfehle dir die Umfangreiche Doku zu lesen und viel zu ueben, Maven hat eine sehr hohe Lernkurve, ohne Doku und Ueben wird das nix.

Ja schon richtig :slight_smile:
Aber die Apache Dokus sind traditionell der Horror, wenn einem konzepttechnisch der EInstieg fehlt :slight_smile:
Und die paar todos haben auch mehr fragen aufgeworfen ^^
Erschwerend kommt hinzu, das mir noch einige Java konzepte fremd sind …

z.b. sourcen aus externen quellen zu holen und „einfach“ zu benutzen ^^ in c++ sind das abhaengigkeits und compilierorgien bis das „automatisch“ funktionieren wuerde.
da gibts dann etwas andere konzepte …

Ciao …

5

das svn plugin ist dann eigentlich nur fuer externe Abhaengigkeiten.
…
z.b. sourcen aus externen quellen zu holen und „einfach“ zu benutzen

Habe dir doch schon erklaert dass das falsch ist, da werden keine Sourcen aus SVN Repos geholt, weder fuer externe Abhaengigkeiten noch fuer sonstwas.

6

Ein Maven Repository ist nichts anderes als ein Verzeichnis mit einer bestimmten Struktur. Wo genau das rumliegt, ist prinzipiell egal. Also kannst du auch alle Abhaengigkeiten (== kompilierte jar Dateien) direkt mit ins Subversion legen. Nur musst du dir dann selbststaendig die Abhaengigkeiten suchen, runterladen und eben in das korrekte Verzeichnis einsortieren. Bei groesseren Projekten ist das die Hoelle und nahezu alle Entwickler, die mit Maven arbeiten, werden davon abraten.

Bei uns ist das Maven Repo schlicht ein Netzlaufwerk, auf das alle zugreifen koennen. Und ja, wir sortieren manuell die Abhaengigkeiten da rein. Ich empfehle das nicht - aber grad um das alles mal auszutesten, ohne neue Software ins Unternehmen bringen zu muessen, ist das eine Alternative, die man zumindest mal diskutieren kann.

Eventuell ist es auch hilfreich, bestehende OpenSource Projekte z.B. auf github anzusehen, die Maven einsetzen (siehst du schnell, wenn eine pom.xml im Rootdir liegt).

7

Habe dir doch schon erklaert dass das falsch ist, da werden keine Sourcen aus SVN Repos geholt, weder fuer externe Abhaengigkeiten noch fuer sonstwas.

Sorry, aber ich versteh das Konzept immer noch nicht …
Wenn alles im Repo liegt, muss ich initial doch eh per svn auschecken.
erst dann hab ich die pom im entsprechenden Verzeichnis auf der Platte.

Wobei unterstützt mich dann das Plugin ?
nur das ich statt {svn commit -m „Commit Message“} {mvn -Dmessage= „Commit Message“ scm:checkin} schreiben kann ?
Also eigentlich nur, um das verwendete SCM zu abstrahieren ? also das es für den maven Nutzer transparent is, ob er git,svn, oder mercurial oder sonstwas nimmt ?

Eventuell ist es auch hilfreich, bestehende OpenSource Projekte z.B. auf github anzusehen, die Maven einsetzen

Ja gute Idee …

Ciao …

8

Ohne alles gelesen zu haben:

Maven zieht sich die Abhängigkeiten aus dem ihm bekannten Repositories. Zunächst aus dem lokalen und wenn dort die Abhängigkeit nicht vorhanden ist, werden die externen Repos angefragt.

Das SVN Plugin ist für das eigene Projekt um dort beim Releasen der eigenen Anwendung z.B. Tags automatisiert setzen zu können.

9

Ich versuch grad mit maven mal was rumzuspielen …
Installation hat auch geklappt , Abhaengigkeiten sind alle da ^^

Nur der Inet Zugriff macht “Probleme”.
Ich hab hier nen Proxy mit “Standard Authorization” …
Also alle Browser, Eclipse, subversion / Tortoise und co schaffen es, einen Authorisation dialog aufgehen zu lassen …

Ok, maven settings aha,

  • proxy eintragen, kein problem
  • username für proxy eintragen, kein problem.

mvn help:effective-settings fails. Proxy authorization !
Äh ja keine Abfrage nachm Passwort ???

Ok, es gibt nen Parameter wo man das Passwort plain in der Settings.xml eintragen kann.
Probeweise gemacht, aha plötzlich funktioniert es.

Passwort wieder raus … fail !

Äh was soll das ?
Ich werd das passwort doch nicht in ein File auf meinen rechner schreiben !
WIr haben hier nen Single Sign-on
Das Passwort wird also noch für wesentlich schlimmere Dinge verwendet.
Und das in nen Textfile schreiben, was ueber die windows domänen controller auf alle rechner verteilt werden, auf denen ich mich jemals einlogge ?
…

Stell ich mich beim configurieren zu doof an oder ist das wirklich nen Problem …

Meine Erwartunghaltung waere, das er das pw auf der console abfragt … muss man das seperat configurieren ?

Ciao …

10

Bis dato scheint es keine andere Möglichkeit zu geben das Passwort anzugeben. Auf der Homepage wird geraten die Zugriffsrechte auf diese Datei entsprechend einzuschränken.

Außerdem ist geplant das Password in Zukunft in eine Keystore Datei auszulagern. Scheint aber keine hohe Prio zu haben diese Maßnahme.

Quelle: http://maven.apache.org/guides/mini/guide-proxies.html

11

Äh was soll das ?
Ich werd das passwort doch nicht in ein File auf meinen rechner schreiben !
WIr haben hier nen Single Sign-on
Das Passwort wird also noch für wesentlich schlimmere Dinge verwendet.
Und das in nen Textfile schreiben, was ueber die windows domänen controller auf alle rechner verteilt werden, auf denen ich mich jemals einlogge ?

Unter Linux bereitet das keine Probleme, weil in deinem Homefolder dort auch private Schluessel etc. liegen und da die Rechte richtig verteilt sein sollten.
PW auf der Konsole wirds nicht geben, Maven laedt ziemlich viel runter :wink:

Nebenbei, Roaming Profiles sind eine wirklich schlechte Idee mit Maven (bzw. Entwickler im allgemeinen), wenn dein lokales Repo im Home Folder liegt werden da jedesmal Gigabytes synchronsiert beim an- und abmelden.
Ist IHMO auch kein Anwendungsfall bei Entwicklern, zumindest wo ich bin/war haben Entwickler bessere Hardware, da meldet man sich nicht irgendwo anders an einem „Sekreaterinnen PC“ an sondern traegt seinen Laptop herum.

12

Nebenbei, Roaming Profiles sind eine wirklich schlechte Idee mit Maven (bzw. Entwickler im allgemeinen), wenn dein lokales Repo im Home Folder liegt werden da jedesmal Gigabytes synchronsiert beim an- und abmelden.
Ist IHMO auch kein Anwendungsfall bei Entwicklern, zumindest wo ich bin/war haben Entwickler bessere Hardware, da meldet man sich nicht irgendwo anders an einem „Sekreaterinnen PC“ an sondern traegt seinen Laptop herum.

Das Repository hab ich schon verschoben an einen nicht gesicherten Ort.
Das ist auch kein problem.

Unter Linux bereitet das keine Probleme

Unter Linux bereitet das keine Probleme, weil in deinem Homefolder dort auch private Schluessel etc. liegen und da die Rechte richtig verteilt sein sollten

Aber nicht im Plaintext hoffentlich ? gehasht klar …

Imho werden die Homdirs in einem Unternehmen entweder exportiert oder auch geynct … damit wenn dir dein Lappy getauscht wird, du einfach nen neuen in die hand bekommst, und es lustig weitergehen kann. Das funktioniert unter Unix/Linux sogar noch weit besser als unter windows. Wir hatten mal nen Pilotproject mit Linux Clients, da wurde das so umgesetzt. Das Homdir warn Export … und auf lokale platten bist gar ned so ohne weiteres rangekommen.

Unter Windows isses bei uns hier auch gang und gäbe … jeder unscheinbare Itler der bestimmte Berechtigungen hat, kann darf und muss sich auf alle, auch meinen, Desktop im Unternehmensnetzwerk per VNC aufschalten und „hilfestellung“ leisten … mit Adminrechten. Das ist bei uns so Philosophie. Wir müssen sogar unterschreiben, das sich die IT das recht vorbehält, alle daten einzusehen (PC ist kein privateigentum, sondern Arbeitsmittel) und auch das wir nirgends passwörter unverschluesselt hinterlegen …

Ich glaub nicht das wir da voll die exoten sind. Kenn noch 2 weitere Firmen im Bereich von mehreren 100 desktop Pc’s die ähnliche Policies haben.
Also wir reden hier von 8K Clients im Netz … individuale Lösungen sind nen absolutes nogo hier ^^

Ciao …

13

Das Repository hab ich schon verschoben an einen nicht gesicherten Ort.
Das ist auch kein problem.

Das bereitet erst Probleme wenn der Rahmen groesser wird :wink:
Habe zB. dafuer gesorgt, dass unsere „Near-Shore Entwickler“ (ueber 20) auch kein Roaming Profile mehr haben weil das sonst sehr Umstaendlich wurde auf Dauer.

Aber nicht im Plaintext hoffentlich ? gehasht klar …

Schluessel liegen so vor wie sie gebraucht werden, also nicht nur „gehasht“.
Wenn das HOME Directory nicht „sicher“ ist, ist es gar nichts :slight_smile:
Verschluesselt wird meist die Platte/Partition.

Imho werden die Homdirs in einem Unternehmen entweder exportiert oder auch geynct … damit wenn dir dein Lappy getauscht wird, du einfach nen neuen in die hand bekommst, und es lustig weitergehen kann.

Nein, wird es eben nicht, zumindest fuer Entwickler, oder es sollte zumindest nicht…
Bessere HW, spezielle Installation/Konfiguration (Virenscanner wird runtergefahren, lokale Admin Rechte, viel SW nur fuer Entwickler ((RDBMS, IDEs, etc. pp.)) die eben nicht ins HOME dir wandert.
Alles in allem kann es nicht „munter weitergehen“ nach einem Wechsel, ist aber kein Problem meistens, „wichtie“ Sachen sind sowieso im zentralen SCM, damit braucht man meist kein grosses Backup und kuemmert sich selber darum.

Zumindest sehe ich das so wenn es um HW & OS fuer Entwickler geht, sind Poweruser welche keine UNterstuetztung bei der Einrichtung von Word etc. brauchen (Word nutze ich zB. seit Jahren nicht mehr), alles in allem ein ganz anderer Anwendungsfall als bei der Sekretaerin, beim CEO, den Vertrieblern, usw. usf.

Ich glaub nicht das wir da voll die exoten sind. Kenn noch 2 weitere Firmen im Bereich von mehreren 100 desktop Pc’s die ähnliche Policies haben.
Also wir reden hier von 8K Clients im Netz … individuale Lösungen sind nen absolutes nogo hier ^^

Die Firma bei der ich gerade arbeite wurde von einem Grosskonzern (12000+ Mitarbeiter) aufgekauft, ist da auch nicht anders als vorher.
IME macht es einen grossen Unterschied ob Technologie bzw. konkret SW Entwicklung zum Kerngebiet zaehlt, dort wo SW Entwicklung nur „nebenbei“ betrieben wird ist es sehr schwer, habe da aber auch schon erlebt dass extra ein eigenes Netzwerk aufgezogen wurde in dem sich die Entwickler austoben konnten. Natuerlich liegt auch viel am „Vorturner“, wenn der das nicht Unterstuetzt wird das nix.

Ansonsten habe ich (und alle Kollegen) mal in einer aehnlichen Situation einen lokalen Proxy installiert weil die Authentifizierung mit dem Windowsserver per Java (Maven) nicht richtig klappte, da kam mein Passwort & Username eben in die Proxy Konfig und alles funzte wieder.

14

IME macht es einen grossen Unterschied ob Technologie bzw. konkret SW Entwicklung zum Kerngebiet zaehlt

alles in allem ein ganz anderer Anwendungsfall als bei der Sekretaerin

Das triffts ziemlich gut :slight_smile:
Für unsere IT gibts nur Admins und Sekretärinnen :slight_smile: Sind halt binär orientiert …
Aber wir merken extrem das wir für die ein „ständiges“ Ärgerniss sind. Lauter Sonderwünsche, Programme die nicht in deren Katalog auftauchen, Admin Rechte und Zugang zu Arbeits-PC, aus Fach-Abteilung Handkassen wird Hardware nachgekauft und in suboptimal konfigurierte Rechner eingebaut, ich glaub die hassen uns wirklich :slight_smile:

Unter Linux bereitet das keine Probleme, weil in deinem Homefolder dort auch private Schluessel etc. liegen und da die Rechte richtig verteilt sein sollten

Hab mal mitm Admin (andere Firma) geschwätzt, und ja der meint ist ne Unsitte, aber leider gängige Praxis, besonders bei nichtkommerzieller oder opensource Software.(ob kommerzielle dann so viel besser ist … ??)

In nem System mit Single Sign-On wie bei uns eigentlich der SuperGau …
Das würde auch mit erklären, warum in unseren Bereich (automotive) so eine generelle Antipathie gegenüber opensource software besteht ^^
Wahrscheinlich auch der Grund, warum wir fuer jeden Sch… unsere Spezial super duper teuer eingekaufte eigenlösung haben (wenns kein M$ Produkt gibt, was man dafuer zweckentfremden könnte ^^)

Ciao …

15

as triffts ziemlich gut
Für unsere IT gibts nur Admins und Sekretärinnen Sind halt binär orientiert …
Aber wir merken extrem das wir für die ein „ständiges“ Ärgerniss sind. Lauter Sonderwünsche, Programme die nicht in deren Katalog auftauchen, Admin Rechte und Zugang zu Arbeits-PC, aus Fach-Abteilung Handkassen wird Hardware nachgekauft und in suboptimal konfigurierte Rechner eingebaut, ich glaub die hassen uns wirklich

Wichtig ist der Helpdesk gleich am Anfang klarzumachen „War ihr da macht koennen wir schon lange“, mal ueberspitzt ausgedrueckt.

Hab mal mitm Admin (andere Firma) geschwätzt, und ja der meint ist ne Unsitte, aber leider gängige Praxis, besonders bei nichtkommerzieller oder opensource Software.(ob kommerzielle dann so viel besser ist … ??)

Naja, je nachdem was man als „Admin“ bezeichnet, „HelpDesk“ bzw. „Desktop Support“ war IMHO nie die Vorzeigegarde dieser Gilde, Serveradmin („Ops“ Typen wie man sie von DevOps kennt) sind da ein ganz anderes Kaliber, Roaming Profiles sind da tabu, die haengen auch in eigenen Netzen herum wo es schlicht keinen Zugriff fuer die Helpdesk gibt :slight_smile:
Von den Desktop-Support-Fuzzis lass ich mir schon lange six sagen, obwohl ich vollstes Verstaednis fuer sie habe wenn sie Desktop supporten, aber wie gesagt, das machen Entwickler am besten selber, aber Windows Admins („Maus Schubser“) nehme ich von Haus aus nicht ernst, vor allem wenn sie etwas von „Sicherheit“ erzaehlen…

Aber wie gesgat, wenn der HOME Folder nicht sicher ist, ist es gar nix.

Ansostnen:
Wer meinst dass er keine OSS einsetzt hat keine Ahnung was er einsetzt (Java geht gar nicht ohne OSS), und Sicherheit bekommst du auch bei OSS, mit Linux besser als mit Windows.
Meinstens sind Maus-Schubser ohne Linux Erfahrung fuer das vermeiden von OSS verantwortlich, klicki-bunti halt…

Habe selber lange Zeit (10+ Jahre) in der Ruestung gearbeitet, „Sicher?“ ist eine sehr komplexe Frage, da reicht es nicht nur nach OSS oder kommerzielle SW zu trennen, vor allem weil das ueberhaupt nix aussagt darueber wie sicher etwas wirklich ist.

16

Meinstens sind Maus-Schubser ohne Linux Erfahrung fuer das vermeiden von OSS verantwortlich, klicki-bunti halt…

Neee, glaub da steckt mehr dahinter… zumindest bei uns. Ich glaub das ist auch eher strukturell bedingt.

  • Lizenz Jungle
    GPL, LGPL sind ja eigentlich klar, und werden mittlerweile hoffentlich verstanden. Aber diese ganzen Zwischen-Lizenzen, glaub da blickt kein „Entscheider“ durch, bzw hat auch „Lust“ sich damit auseinanderzusetzen.
    Für Grenzfälle Unklarheiten besteht auch immer bissi rechtsunsicherheit, das mag natürlich keine Firma.

  • Weiterentwicklung
    „Wir kaufen, Ihr liefert dafür was **wir **wollen“ ist logischer weisse die Lieblings-Einstellung.
    bei opensource tools ist weiterentwicklung halt nicht garantiert. Und man scheut sich selbst dafuer da aktiv zu werden.
    Beispiel bei uns. Wir vervenden subversion, und auch python scripts (open source).
    und es „kracht“ regelmaessig, weil irgendwer die aktuellen tortoises installiert, die ne neue subversion nutzen, die nen neues lokales fileformat haben …
    und „pysvn“ schaffts nicht, einigermassen zeitnah versionen zu liefern, das man python auch mit neueren svn versionen zum laufen bekommt ^^
    Das ist zum Beispiel ein vielzitiertes Beispiel für „Opensource taugt soweiso nix“ … :slight_smile:

Einkauf:
Der iss bei uns traditionell nen sehr möchtiges organ.
Und wenn der berichten kann, wir haben 20% von … aehm 0 Euro … rausgehandelt, klingt halt ned so gut ^^
und für 0 Euro kann man wen auch schlecht verklagen ^^

WObei das früher schon schlimmer war. Es tut sich schon was bissi mehr in Richtung OSS. Es gehen mehr DInge. Aber OSS freundlich sind wir noch lange nicht.

Und die andere Sache ist, im rein finanziellen Aspeckt rechnet sich OSS anders …
Windows ist für unseren Einkauf sicher „fast“ Freeware. Gerüchten zu Folge kostet mich die Tasse Kaffee auf Arbeit (ja ich weiss, woanders bekommt man die auch umsonst) mehr als wie eine Windows Lizenz hier :slight_smile:
WIr beziehen aber auch andere Leistungen von denen. Zumindest genug als das die oft und gerne mal bei uns verbeischauen ^^

Ciao …

17

Dafuer kann OSS nun aber wirklich nichts.

[QUOTE=HBerger;72453]Beispiel bei uns. Wir vervenden subversion, und auch python scripts (open source).
und es „kracht“ regelmaessig, weil irgendwer die aktuellen tortoises installiert, die ne neue subversion nutzen, die nen neues lokales fileformat haben …
und „pysvn“ schaffts nicht, einigermassen zeitnah versionen zu liefern, das man python auch mit neueren svn versionen zum laufen bekommt ^^
Das ist zum Beispiel ein vielzitiertes Beispiel für „Opensource taugt soweiso nix“ … :slight_smile: [/QUOTE]
Das ist ein bissel wie, wenn jemand regelmaessig die Handbremse im Auto abbaut und anschliessend ueber den Hersteller meckert, weil das Auto wegrollt.
Exakt dein Beispiel kann man auch mit bezahlter Software „umsetzen“.

? Das ist jetzt wirklich absurd. Wenn etwas 0 Euro kostet und etwas anderes 1’000’000 Euro - wen interessieren da 20% ?

Sehr wahr und auch gut so! Denn meistens (99,9%) sitzt der Fehler vor dem Monitor - und eben nicht beim Hersteller. Man sagt auch „Nein, SELECT ist nicht kaputt!“.

Natuerlich, und sie gehen erst mit einem neuen Vertrag. Hilfreich sind diese Leute selten. Wobei ich von MS nur wenige kenne, dafuer sind hier oefter mal welche von Oracle. Und wirklich hilfreich ist der Hinweis auf die Enterprise Edition selten :wink:

Ich glaube, du hast irgendwie ein falsches Verstaendnis von OpenSource. Da wird dir nix geschenkt, wofuer andere viel Geld verlangen. OpenSource bedeutet, dass die Technologie, die Idee, die Umsetzung, die Doku usw. frei verfuegbar fuer jeden sind. Nicht mehr und nicht weniger. Es dient in erster Linie dazu, Dinge lernen zu koennen, weil sie eben frei sind. OSS ist sogar so frei, dass man sie selbst weiter entwickeln/bugfixen kann - auch wenn der Hersteller der ClosedSource-Alternativloesung bereits pleite ist. Und das ist ein echter Vorteil, gerade auch fuer grosse Unternehmen!

Aber das mit dem kaufen und verklagen ist halt viel einfacher. „Huch, unsere Software geht nich? Ach, ist doch die XXX DB, die Deppen koennen einfach nuescht!“ Schuldzuweisung ist meistens einfacher als Fehlerbehebung.