# Neue JEE Infrastruktur aufsetzen



## deetee (18. Apr 2012)

Hallo,

ich bin noch recht neu im JEE Umfeld und bin aktuell am überlegen, wie denn eine zukunftssichere JEE Umgebung aussehen könnte. Fragen die mich beschäftigen:


Ist es sinnvoll 2-3 Application Server grundsätzlich zu unterstützen oder sollte man sich auf einen festlegen?
Bietet mir Spring genügend Vorteile gegenüber der aktuellen JEE Technologie?
Was muss ich beachten, wenn ich eine Infrastruktur aufbauen möchte die für Web und Mobile gleichermaßen taugt? Also doch Spring?
Welche Frameworks sollten benutzt werden? JPA oder Hibernate? JSF oder sonstige?
Projekte, Module, Libs sollen möglichst einheitlich erstellt werden. Maven oder ANT?
Testing ist sehr wichtig. Welches Framework sollte ich nehmen? JUnit oder TestNG?
CI ist ebenfalls wichtig. Auch hier gibt es viele Lösungen. Apache Continuum würde mich interessieren, aber Hudson ist wohl am verbreitesten, oder?
Wie organisiere ich am saubersten die Klassenbibliotheken, wenn ich Libs für Android, Web, Web Start, Webservices und evtl. Desktop schrieben möchte?

Es geht mir wirklich um einen flexiblen und nicht spezialisierten Technologie Stack. Wie würdet ihr so eine "Grüne Wiese" Infrastruktur aufsetzen?


----------



## Marcinek (18. Apr 2012)

Gratz:

8 Threads in einem. Zu jedem kannst du Bücher schreiben. Und gleichzeitig ist das mein Tipp zu den Themen. Kauf dir Bücher oder:

Ich schlage hier ein Studium der Informatik vor. Anschließend 2 oder 3 Jahre Berufserfahrung auf diesem Gebiet und dann kann man sich diese Themen mal anschauen.

So Grüne Wiese Threads wirst du nun zu jedem deiner 8 Themen von 10 Usern 80 Meinungen haben.


----------



## deetee (18. Apr 2012)

Ich habe ein Informatik Studium hinter mir, ebenso 3 Jahre Berufserfahrung als Softwareentwickler und ich hab sogar das ein oder andere Buch gelesen. Trotzdem bin ich kein JEE Experte und habe wenig Erfahrung mit dem Wandel in der Java Welt allgemein.

Daher stelle ich mir Fragen wie diese, die ich locker beantworten könnte, wenn es um PHP gehen würde. Da gibt es zwar weniger Technologien, dennoch denke ich, dass jemand mit ähnlichem Erfahrungsstand im Java Umfeld zu solchen Fragen eine Meinung hat und vielleicht sogar Argumente.

Ich bin hier nicht oft unterwegs, aber ich hoffe solche erfahrenen Leute gibt es hier.


----------



## Marcinek (18. Apr 2012)

deetee hat gesagt.:


> Ist es sinnvoll 2-3 Application Server grundsätzlich zu unterstützen oder sollte man sich auf einen festlegen?



Nein es ist nicht sinnvoll. Auch bei einem Wechsel von JBoss X => Jboss X+1, können Probleme entstehen, wenn man zuviel Features des Application Servers nutzt.



deetee hat gesagt.:


> Bietet mir Spring genügend Vorteile gegenüber der aktuellen JEE Technologie?



Spring (Framework) ? Wikipedia



deetee hat gesagt.:


> Was muss ich beachten, wenn ich eine Infrastruktur aufbauen möchte die für Web und Mobile gleichermaßen taugt? Also doch Spring?



Lose gekoppelte Technologien verwenden. Spring ist nur eine mögliche Implementierung. Meine aktuelle Hobbyimplementierung supportet alle möglichen Clients ohne den Einsatz von Spring.



deetee hat gesagt.:


> Welche Frameworks sollten benutzt werden? JPA oder Hibernate? JSF oder sonstige?



Unmöglich zu beantworten ohne die Anforderungen zu kennen. Hibernate ist eine JPA Implementierung.



deetee hat gesagt.:


> Projekte, Module, Libs sollen möglichst einheitlich erstellt werden. Maven oder ANT?



Maven und Ant sind erstmal grundverschiedene Frameworks. Während Maven ein Buildtool darstellt, würde ich ANT in eine Art Batch verarbeitung packen.



deetee hat gesagt.:


> Testing ist sehr wichtig. Welches Framework sollte ich nehmen? JUnit oder TestNG?



Ich benutze JUnits.



deetee hat gesagt.:


> CI ist ebenfalls wichtig. Auch hier gibt es viele Lösungen. Apache Continuum würde mich interessieren, aber Hudson ist wohl am verbreitesten, oder?



Ich benutze Hudson.





deetee hat gesagt.:


> Wie organisiere ich am saubersten die Klassenbibliotheken, wenn ich Libs für Android, Web, Web Start, Webservices und evtl. Desktop schrieben möchte?



I.d.R. würde das die Berufserfahrung / Programmiererfahrung liefern. Ich weiß nicht, was du hier als antwort erwartest.

Das ist eine Frage, die Studium + Berufserfahrungen liefern und kein Forum.

Bei jemanden, der studiert und drei Jahre Berufserfahrung hat, würde ich erwarten, dass er sich mit dem Thema zunächst vertraut macht und dann gezielte punktuelle Fragen stellt. Man sieht aber hier, dass nicht nur das Projekt bei 0 anfängt, sondern auch deine Erfahrung auf diesem Gebiet. 

Ich habe im Studim gelernt, wie man Informationen effizient herausbekommt.


----------



## deetee (18. Apr 2012)

Vielen Dank für die Antworten, jede Meinung ist für mich interessant. Über so ein Forum lernt man ganz gut die "community" kennen.

Zum Thema Klassenbibliotheken. Ich versuche mal meinen spontanen Ansatz zu erläutern, wie ich mir sowas vorstellen könnte.

Also ich würde in meinem Versionskontrollsystem ein repository für Android (nochmal aufgeteilt in web und native), Web, Web Start (wobei Webstart evtl. auch unter Desktop laufen könnte?) und Desktop erstellen.

Die nächste Frage ist das Packaging. Alles immer als JAR oder macht man das bei wenigen Klassen pro Lib nicht? Wenn nein, warum?

Ich denke es gibt auf keine meiner Fragen nur eine einzige Möglichkeit als Antwort. Ganz klar. Aber ich denke ein paar Anregungen darf ich mir doch hier erhoffen. Nur bitte kein "Krieg der Welten". Jede Technologie hat Vor- und Nachteile, darüber muss man nicht streiten.


----------



## DerFeivel (19. Apr 2012)

deetee hat gesagt.:


> Hallo,
> [*]Ist es sinnvoll 2-3 Application Server grundsätzlich zu unterstützen oder sollte man sich auf einen festlegen?



Kommt drauf an, was die Rahmenbedingungen sind. Hast du die Zeit/die nötigen Leute um dich in die unterschiedlichen Konfigurationen und Eigenheiten der Server einzuarbeiten (als Beispiel fällt mir hier Jaas-Datenbankrealm auf dem JBoss <-> Glassfish ein)?
Ansonsten eher sich anfangs auf einen festlegen und dann, sofern nötig, auf andere anpassen.



> [*]Bietet mir Spring genügend Vorteile gegenüber der aktuellen JEE Technologie?



Auch hier kommt es wieder auf die Rahmenbedingungen an. Hast du nur einen Applicationserver würde ich mich wahrscheinlich für Spring entscheiden, da die Features hier oftmals wesentlich angenehmer/leicher umzusetzen sind, als gegen den Standard.
Bei mehreren ASen habe ich aber bisher gegen den Standard und die Specs programmiert, da dir das die Integration von Spring-Version X in AS Y erspart und trotzdem meist auch recht schnell von der Hand geht.



> [*]Was muss ich beachten, wenn ich eine Infrastruktur aufbauen möchte die für Web und Mobile gleichermaßen taugt? Also doch Spring?



Die Rahmenbedingungen...konkreten Anforderungen...



> [*]Projekte, Module, Libs sollen möglichst einheitlich erstellt werden. Maven oder ANT?



Persönlich möchte ich maven nicht mehr missen. Es ist zwar am Anfang recht ungewohnt und teilweise nicht leicht zu verstehen, allerdings würde ich behaupten, dass es ein riesiger Time-Safer ist...



> [*]Testing ist sehr wichtig. Welches Framework sollte ich nehmen? JUnit oder TestNG?


JUnit....TestNG habe ich keine Erfahrung.


----------



## stareagle (19. Apr 2012)

Hallo,



deetee hat gesagt.:


> Bietet mir Spring genügend Vorteile gegenüber der aktuellen JEE Technologie?


Meiner Meinung nicht, wenn du Java EE 6 einsetzt. Zumindest von Dependency Injection angeht ist Java EE mit der Version mit Spring gleichgezogen. Trotzdem sollte man das anhand der Anforderungen des konkreten Projektes entscheiden. 



deetee hat gesagt.:


> Welche Frameworks sollten benutzt werden? JPA oder Hibernate? JSF oder sonstige?



JSF und JPA sind Teil von Java EE. Hibernate ist eine Implementierung von JPA, bietet aber auch noch eine eigene API. Die würde ich aber eher als Altlast betrachten. Denn Hibernate selbst ist älter als die JPA.



deetee hat gesagt.:


> Projekte, Module, Libs sollen möglichst einheitlich erstellt werden. Maven oder ANT?



Es gibt zuviele Randbedingungen, die hier eine Entscheidung erschweren. Hier sind ebenfalls die konkreten Anforderungen des Projektes ausschlaggebend. Auch wenn ich persönlichen Maven bevorzuge: Es gibt noch weitere Build-Tools im Java-Umfeld, z.B. Gradle (wird bein einigen der Subprojekte von JBoss verwendete).



deetee hat gesagt.:


> Testing ist sehr wichtig. Welches Framework sollte ich nehmen? JUnit oder TestNG?


Zusätzlich zu JUnit oder TestNG solltest du dir Arquillian anschauen. Arquillian erleichert das Testen von JavaEE-Anwendungen enorm, da es erlaubt EJBs und Co. innerhalb des Application Servers zu testen. Es ist zwar ein JBoss-Projekt, unterstützt aber auch andere Application-Server.

Beste Grüße

Stareagle


----------



## FArt (20. Apr 2012)

Wie schon gesagt kommt es auf die konkreten Anforderungen an die Projekte und die Entwickler und deren Vorkenntnisse und Können an.

Bei komplett grüner Wiese würde ich (mit meinen Vorkenntnissen, Erfahrungen und in meiner Umgebung, sprich mit den Kollegen mit denen ich es zu tun habe) das als ersten Wurf verwenden:
Agile Entwicklung (Scrum, Kanban, XP, ...), CDI (mit und ohne JBoss 7.1), JPA oder Hibernate, Gradle für den Build, Spock oder JUnit für Testing (mit Arquillian), CI z.B. Jenkins, Sonar und eine mavenized Struktur, evtl. auch OSGi.

Wichtig:  immer so designen und entwickeln, dass es möglich ist, einzelne Entscheidungen nach ersten Erfahrungen zu hinterfragen und abzuändern, bzw. manche Entscheidungen nicht zwingend für alles sein kann/muss. Wichtig ist ständige Reflektion ...


----------



## deetee (23. Apr 2012)

Vielen Dank für die letzten paar Antworten.

Aktuell halte ich folgende Infrastruktur für sinnvoll:


Eclipse als IDE (Netbeans hat knapp verloren, ausschlaggebend war die Android Unterstützung)
Maven als Standard Tool für Projekt/Modul Templates. Evtl. ANT als zusätzliches Tool falls notwendig.
Versionskontrolle mit GIT (das wird wohl schwierig, da SVN bereits hoch etabliert ist)
CI Server (Jenkins/Hudson oder Continuum, hier muss noch entschieden werden)
QA Tools nutzen: Sonar
ORM mit JPA (ich habe zwar keine Erfahurng mit Hibernate, aber wozu ein fremdes Framework, wenn nicht notwendig?)
Entwicklung mit Spring (noch nicht zu 100% entschieden, aber Effizienz und Flexibilität sprechen wohl für Spring)
Application Server: JBoss oder Glassfish, weil es hierzu auch die meisten Tutorials zu geben scheint. Ich werde aber noch prüfen, ob mit Spring ein AS überhaupt notwendig wäre oder Tomcat ausreicht. Falls ich mich doch gegen Spring entscheide, könnten auch beide unterstützt werden. Andere AS (Websphere, WebLogic) scheinen mir weniger verbreitet zu sein und daher wäre der Aufwand sie zu unterstützen wohl nicht rentabel.
Testing: Läuft wohl auf TestNG mit Arquillian hinaus.



Nun habe ich noch ne Frage:

Ich habe von XDoclet in diversen Tutorials gelesen. Wie etabliert ist dieses Framework in der Java Welt?


----------



## maki (23. Apr 2012)

Mein Senf:

- SVN läuft und ist etabliert, wozu jetzt auf GIT wechesln bzw. welch Vorteile würdend as rechtfertgen?
- JBoss/Glassfish und Spring? Welches konkretes Problem soll das denn lösen?

Kennst du dich denn wirklich gut mit Maven aus bzw. habt ihr jemanden der sich auskennt?

XDoclet ist sein Java 5 irrelevant...


----------



## deetee (24. Apr 2012)

Ich denke Git wird SVN in den nächsten 2-3 Jahren ablösen, weil es insgesamt doch das bessere CVS ist. Ich denke das verhält sich ähnlich wie ANT und Maven momentan, wobei Maven sicher etwas früher ANT ablösen wird.
Persönlich kenne ich mich auch besser mit SVN noch aus, aber gerade Branching bzw. das Mergen ist mit SVN in mittelgroßen Teams schon echt kompliziert. Das macht Git effizienter, eben ähnlich wie Maven vieles effizienter macht als ANT.


Spring werde ich noch etwas genauer betrachten, eben um zu prüfen, ob ein AS dann überhaupt notwendig wäre oder ob ein Tomcat schon reicht.

Also richtig gut kenne ich mich mit Maven sicher noch nicht aus, aber wieso ist das wichtig? Die ganze Open Source Welt steigt gerade auf Maven um, da wird es nicht ausbleiben, dass Maven gelernt werden muss.

Gut zu wissen, dass XDoclet nicht mehr gebraucht wird.


----------



## kama (24. Apr 2012)

Hi,



deetee hat gesagt.:


> Ich denke Git wird SVN in den nächsten 2-3 Jahren ablösen, weil es insgesamt doch das bessere CVS ist. ...


Hm...



deetee hat gesagt.:


> Persönlich kenne ich mich auch besser mit SVN noch aus, aber gerade Branching bzw. das Mergen ist mit SVN in mittelgroßen Teams schon echt kompliziert. Das macht Git effizienter,



Hm. Dazu fällt mir nur ein:

A fool with a tool is just a fool...

Das Problem ist nicht Git/SVN sondern die Branching Strategie die dahinter steckt und wenn Du schonmal mit 200 Entwicklern eine Branching-Strategie gemacht hast dann ist es egal, ob nun SVN oder Git...beides ist komplex...

Gruß
Karl Heinz Marbaise


----------



## Marcinek (24. Apr 2012)

Ich kann gerade nicht zitieren, aber ich beziehe mich auf das letzte Posting des tos@

Du schreibst, dass du studiert und berufserfshrung hast. Zeigen tust du das hier nicht wirklich... 

1) git wird svn ablösen.

Hast du hierfür irgendwelche empirischen Daten? Imho haben beide Systeme ihre daseinsberechtigungen und die werden sich sicherlich nicht ablösen. Schon gar nicht in den nächsten 3 Jahren. 

2) maven wird ant ablösen.

Man merkt ganz deutlich, dass du dich mit keinen von beiden auseinander gesetzt hast. Das sind ganz unterschiedliche Programme. Imho stehen die nicht in wirklicher konkurenz miteinander


----------



## deetee (24. Apr 2012)

Nicht gleich angegriffen fühlen von meiner Meinung. Wenn ich sage, dass SVN oder ANT abgelöst werden, dann meine ich lediglich, dass die Verbreitung und Nutzung wohl zurückgehen wird und eine neue Technologie die Nummer 1 sein wird. Das hat sich in der Vergangenheit gezeigt, als CVS durch SVN abgelöst wurde. Und da ich eben die Probleme von SVN in der Praxis kenne, und den Verlauf von Git beobachte (Community, Tool Unterstützung, KnowHow in Unternehmen, etc.) komme ich eben zu dieser Einschätzung. Die muss nicht stimmen, ganz klar. Wäre ja schön, wenn ich sowas vorhersehen könnte.

Tja, und was ANT und Maven angeht, da liegst du falsch. Natürlich kenne ich die Unterschiede von ANT und Maven, dennoch kann man ANT durch Maven ersetzen oder zumindest Teilaufgaben, die man bisher mit ANT gemacht hat, nun durch Maven erledigen lässt. Sicher kann es sein, dass ANT in Projekten fest verankert ist, da Maven nicht alle ANT Aufgaben erledigen kann.

Und wenn du dich schonmal mit Maven auseinandergesetzt hast, dann weißt du ja, wie ineffizient die Arbeit mit ANT wirklich ist im Arbeitsalltag. Die Teile die man mit Maven 2 (Version 1 vergessen wir mal, ist ja auch komplett anders. Vielleicht meinst du noch die 1er Version?) umsetzen kann, vereinfachen die Arbeit enorm.

Maven und ANT stehen für mich durchaus in Konkurrenz, wenn auch nicht zu 100%. Aber der Trend in Unternehmen und Open Source Projekten geht deutlich Richtung Maven (und Git). Dazu braucht man keine Statistiken, das ist so deutlich, dass es auffällt. Wenn du dich etwas im Open Source Bereich auskennst, dann solltest du gemerkt haben, dass in den letzten 2 Jahren einige Projekte auf Git bzw. Github umgestellt haben, und auch deutlich mehr Maven nutzen.


----------



## deetee (24. Apr 2012)

kama hat gesagt.:


> Das Problem ist nicht Git/SVN sondern die Branching Strategie die dahinter steckt und wenn Du schonmal mit 200 Entwicklern eine Branching-Strategie gemacht hast dann ist es egal, ob nun SVN oder Git...beides ist komplex...



Projekte mit 200 Entwicklern sind nicht Normalität in Unternehmen und daher ist dieses Argument in einer Tool Analyse eher zu vernachlässigen.
Im OS Bereich sind 200 Entwickler keine Seltenheit, aber genau deswegen entscheiden sich viele Projekte ja für Git. Wenn man mit 200 Entwicklern arbeitet, dann sitzen die ja wohl selten in einem Gebäude. Deswegen wurde Git überhaupt entwickelt: Verteilte Teams und ein solides Branching Konzept.

Git ist gerade für SVN Umsteiger etwas kompliziert. Ich hab durchaus meien Schwierigkeiten mit Git, aber das sind Dinge die man erlernt. Git ist eigentlich etwas einfacher als SVN, nur ist das Umdenken nach X Jahren SVN das größte Problem.

Ich habe ähnliche Umdenk-Probleme auch bei NoSQL Schemata erlebt. Wenn ein Entwickler zum ersten mal ein nicht-relationales DB Schema erstellen soll, dann werden da einfach Fehler gemacht, weil sowas immer Lernzeit benötigt. Aber ich möchte damit jetzt auch kein neues Fass aufmachen. Keine Sorge, ich behaupte nicht, dass RDBMS durch NoSQL Alternativen ersetzt werden


----------



## maki (24. Apr 2012)

> Wenn man mit 200 Entwicklern arbeitet, dann sitzen die ja wohl selten in einem Gebäude. Deswegen wurde Git überhaupt entwickelt: Verteilte Teams und ein solides Branching Konzept.


Der dezentrale Aspekt an Git passt nicht immer besser als das zentralisierte Modell von SVN.
Nebenbei, ja, 200 Entwickler sitzen nicht selten im selben Gebäude, kommt immer auf das Projekt an.

Für OSS Projekte passt Git oft besser, liegt in der Natur der Sache, dazu kommt, dass Git für ein eben solches OSS Projekt (Linux Kernel) entwickelt wurde.



> Also richtig gut kenne ich mich mit Maven sicher noch nicht aus, aber wieso ist das wichtig?


Weil man maven nicht im handumdrehen lernt, ist recht komplex & eine Blackbox deren Details man kennen muss wenn mal etwas nciht mehr geht.
Dazu kommt dass die Konzepte die Maven  umsetzt, Konfigurationmanagement, depdencyManagemtn etc. pp. auch recht komplex sind, mal vom Tool abgesehen.
Ach ja, Maven 2 ist veraltet, Maven 3 ist aktuell.

Wenn du vorhast gleich soviele neue Tools einzuführen, dann solltest du entweder Erfahrung darin haben oder dich auf eine schmerzliche Erfahrung gefasst machen, ist nicht böse gemeint, aber nur weil etwas häufig verwendet wird heisst es nicht dass es einfach zu erlernen ist.
Maven macht zB. keinen Sinn (für ein Unternehmen bzw. mehrere Entwickler am selben Standard) ohne Repo Manager, also noch ein Tool/Server mehr zu installieren/konfigurieren/warten/etc. pp.

Zum Schluss sind die Technologien für den Kunden/Chef meist nur nebensächlich, klassischer Nerd Fehler nur in Frameworks und Containern zu denken 

Habe selber schon die Erfahrung machen müssen (bei Kunden) dass eine halbherzig aufgesetzte aber dafür überdimensionierte Infrastruktur ohne jemanden der sich auskennt und dafür Zeit hat schell mehr Probleme macht als sie löst...


----------



## Marcinek (24. Apr 2012)

deetee hat gesagt.:


> Tja, und was ANT und Maven angeht, da liegst du falsch.



Angenommen diese Aussage stimmt.



deetee hat gesagt.:


> Sicher kann es sein, dass ANT in Projekten fest verankert ist, da Maven nicht alle ANT Aufgaben erledigen kann.



Was bedeutet, dass ant was anders ist (nämlich ein Stapelverarbeitungsproramm) und Maven ein buildtool ist. 
Damit ist das aber ein Wiederspruch zu oben ;D

Der Grad der Komplexität eines ANT Scripts verhält sich linerar zur Größe des Projekts. Während Maven nun mind. Quadratisch ist ^^

http://www.iternum.com/knowhow/guidelines/maven-vs-ant/document.pdf



deetee hat gesagt.:


> Aber der Trend in Unternehmen und Open Source Projekten geht deutlich Richtung Maven (und Git). Dazu braucht man keine Statistiken, das ist so deutlich, dass es auffällt.



Schwachsinn. Wenn du hier ein Argument bietest, dann belege es bitte mit Statistiken. Ansonsten können sich direkt zwei A-Meisen treffen und über die Relativitätstheorie fachsimpeln.


----------



## kama (24. Apr 2012)

Hi,



deetee hat gesagt.:


> Ich denke Git wird SVN in den nächsten 2-3 Jahren ablösen,


Das bezweifele ich sehr stark....da viele Unternehmen derzeit von den sog. großen Systemem wie ClearCase, IBM Synergy, MKS etc. auf Subversion umsteigen...bei denen wird definitiv nicht auf Git gegangen...

Vielen Unternehmen haben nun mal Angst den gesamten Quellcode plus die gesamte History auf die Rechner zu transportieren...abgesehen davon eigenen sich einige Projekte in der Industrie dazu nicht...da helfen auch Submodules in Git nicht...die sind nicht wirklich Nutzbar geschweige denn bequem...Die andere Frage ist auch: Will ich überhaubt die gesamte Historie mit auf dem Rechner haben..

Und oft wird dann bei Git immer vergessen, dass man auch in einem Unternehmen immer einen Zentralen Punkt haben muss. Nämlich der Punkt von dem aus der aktuelle Stand des Projekte gebaut wird...Stichwort: CI

Ich nenne das gerne *"Organisatorisch Zentralisiertes Versionskontroll System (OZVS)"...*



deetee hat gesagt.:


> weil es insgesamt doch das bessere CVS ist.


Was ist denn besser? Worauf Bezogen? Das gibt es schlicht nicht.
Git und SVN sind einfach unterschiedlich...und haben unterschiedliche Stärken und Schwächen..
Weiterhin gehe ich mal davon aus dass "CVS" ein typo was und eigentlich "VCS" gemeint war...aber CVS wird auch noch eingesetzt und ist noch mehr verbreitet als man denkt....Eclipse hat ja auch recht lange gebraucht um von CVS weg zu gehen...




deetee hat gesagt.:


> Ich denke das verhält sich ähnlich wie ANT und Maven momentan, wobei Maven sicher etwas früher ANT ablösen wird.[/QUOTE
> Das glaube ich auch nicht. Da die Verbreitung von Ant sehr hoch ist...
> 
> 
> ...


----------



## deetee (25. Apr 2012)

Oh man, nehmts mir nicht übel, auf alles kann ich nicht antworten, dafür hab ich keine Zeit.



> Das bezweifele ich sehr stark....da viele Unternehmen derzeit von den sog. großen Systemem wie ClearCase, IBM Synergy, MKS etc. auf Subversion umsteigen...bei denen wird definitiv nicht auf Git gegangen..


Das stimmt, aber die großen Firmen laufen den Trends immer hinterher. Einfach deswegen, weil eine Umstellung/Migration mit hohem Aufwand verbunden ist. Die großen Firmen sind selten die, die zukünftige Standards als erste einsetzen. Der Mittelstand und Open Source sind die Trendsetter.



> aber CVS wird auch noch eingesetzt und ist noch mehr verbreitet als man denkt....Eclipse hat ja auch recht lange gebraucht um von CVS weg zu gehen...


Sicher wird CVS noch eingesetzt, aber warum ist die Frage. Zu hoher Migrationsaufwand auf SVN? Fehlendes SVN KnowHow in den Unternehmen? Gründe gibt es bestimmt, aber das macht CVS nicht wirklich besser als es ist. Ein VCS ohne atomare commits möchte ich nichtmal in einem Einmann-Projekt nutzen, wenn ich eine bessere (ja das gibts auf jedenfall) Alternative habe. Ich sehe bei Git und SVN einige Parallelen zu CVS und SVN damals. 



> Was ist an Branching/Mergen einfach? Das ist egal womit ob mit SVN oder Git ...
> Wenn Du mit 150 Branches arbeitest ist es egal...ob mit SVN oder Git...bei beiden fällst Du richtig auf die sch...ze wenn Du nicht ein ordentliches Branching Konzept hast...


Mit Git kann man durch cleveres Staging Branches vermeiden. Bei SVN geht das höchstens mit "cleverem" committen, was verdammt fehleranfällig ist und daher keine Alternative zum Staging darstellt.



> Hm. in wie fern? Weil es angeblich schneller ist ? oder wie ? Hier geht es um das Branchen/Mergen und das geht mit SVN und Git...


Git bringt das Staging Konzept zusätzlich mit, und wenn man das richtig nutzt in der Entwicklung, dann ist die Entwicklung effizienter. Das zu lernen ist das Problem, es ist ein anderes Arbeiten, als mit SVN. Branchen und Mergen geht mit beiden, da hast du recht, aber Staging geht nur mit Git, das ist der Unterschied, der Git effizienter macht gegenüber SVN. Allerdings machen viele den Fehler Git wie SVN zu benutzen.



> Zum Schluss sind die Technologien für den Kunden/Chef meist nur nebensächlich, klassischer Nerd Fehler nur in Frameworks und Containern zu denken


Die Technologie mag für viele Kunden und Chefs nebensächlich sein, aber in Frameworks denken ist enorm wichtig finde ich. Die Auswahl der Technologien (also auch Frameworks) ist oft eine strategische Entscheidung, und daher existenziell für das Unternehmen. Daher ist es kein Nerd Fehler, sondern eher eine Management Disziplin.



> Maven macht zB. keinen Sinn (für ein Unternehmen bzw. mehrere Entwickler am selben Standard) ohne Repo Manager, also noch ein Tool/Server mehr zu installieren/konfigurieren/warten/etc. pp.


Vielen Dank, ich dachte mir schon, dass die Einführung von Maven eine neue Rolle benötigt (Repo Manager). Das ist aber weniger ein Problem, den nviel Spezialwissen braucht dieser nicht.
Wenn ich da an die ANT Skripte in den Projekten denke, die jeder Entwickler mühevoll verstehen musste, bevor er sie bearbeitet, da ist mir ein Repo Manager weitaus lieber. Irgendwann werden ANT Skripte so komplex, dass derjenige der sich mit einem besonders gut auskennt, ziemlich nahe an die Rolle eines Repo Managers rankommt. Jedes ANT Skript ist anders, das ist ein Problem, was man nicht unterschätzen sollte.



> Schwachsinn. Wenn du hier ein Argument bietest, dann belege es bitte mit Statistiken. Ansonsten können sich direkt zwei A-Meisen treffen und über die Relativitätstheorie fachsimpeln.


Du kannst durchaus andere Erfarungen haben. Schwachsinn ist jedenfalls dein Kommentar. Wenn du vernünftig formulierst, dann antworte ich auch gerne mit den Fakten, die zu meiner Meinung geführt haben.



> Ist Maven schneller als ANT ?


Es geht bei Effizienz darum, wie schnell man mit einem Tool arbeiten kann mit entsprechender Qualität. Dabei gehts nicht primär um die Geschwindigkeitsunterschiede der Tools ansich, sondern eher um die Zeitersparnis bei der Arbeit mit den Tools. Mit Maven sagt man WAS man machen möchte, bei ANT muss man das WIE selbst implementieren durch ANT scripts. Das ist ineffizient im Vergleich zu Maven. Und Zeit ist immer der kritischste Faktor für den Entwickler.


----------



## JohannisderKaeufer (25. Apr 2012)

Oh, es kann durchaus darauf ankommen wie schnell gebaut wird.

3 Minuten oder 15 Minuten für einen Build können schon einiges ausmachen. 
JRebel ist ein super Beispiel, wie "Redeploy-Arm" gearbeitet werden kann.


----------



## deetee (25. Apr 2012)

JohannisderKaeufer hat gesagt.:


> Oh, es kann durchaus darauf ankommen wie schnell gebaut wird.
> 
> 3 Minuten oder 15 Minuten für einen Build können schon einiges ausmachen.
> JRebel ist ein super Beispiel, wie "Redeploy-Arm" gearbeitet werden kann.


Das hab ich nicht bestritten. Es ist aber zu kurz gedacht, wenn man Effizienz mit Performance gleichsetzt.


----------



## schalentier (25. Apr 2012)

kama hat gesagt.:


> Vielen Unternehmen haben nun mal Angst den gesamten Quellcode plus die gesamte History auf die Rechner zu transportieren...abgesehen davon eigenen sich einige Projekte in der Industrie dazu nicht...da helfen auch Submodules in Git nicht...die sind nicht wirklich Nutzbar geschweige denn bequem...Die andere Frage ist auch: Will ich überhaubt die gesamte Historie mit auf dem Rechner haben..



Also ein Unternehmen, dass Angst vor Entwicklern mit Zugriff auf den Quelltext hat, duerfte nicht lange existieren - oder ich versteh deinen Satz ueberhaupt nicht.

Wenn du einmal mit Git gearbeitet hast (besonders in einem (wirklich) groessen Projekt), dann wirst du den Vorteil verstehen, die History komplett lokal vorhanden zu haben. Schonmal ein "Blame" (bzw. Annotate) mit SVN probiert? Das kann u.U. seeehr lange dauern, deswegen wird es selten eingesetzt. Mit Git dauert das selbst bei den sehr haeufig geaenderten Dateien (mit einer entsprechend langen History) nur wenige Augenblicke - weil ja alles lokal da ist. Alleine das ist schon ein Vorteil.



kama hat gesagt.:


> Was ist an Branching/Mergen einfach? Das ist egal womit ob mit SVN oder Git ... Wenn Du mit 150 Branches arbeitest ist es egal...ob mit SVN oder Git...bei beiden fällst Du richtig auf die sch...ze wenn Du nicht ein ordentliches Branching Konzept hast...



Mit Git ist Branchen/Mergen wirklich einfach. Der Grund dafuer ist, dass sich Git genau merkt, wann jemand was und wie gemergt hat. SVN macht das inzwischen auch (indem es die SVN Properties dafuer missbraucht). Nur kann man dabei so viele Fehler machen (z.B. im falschen Verzeichnis mergen, wodurch die kompletten SVN Merge-Properties durcheinander gehauen werden koennen). Danach hat man ein echtes Problem. Bei Git kann man nicht viel kaputt machen. Alles was man zum zentralen Repo pusht, kann man wieder rueckgaengig machen, man kann Commits umsortieren, man kann einen einzelnen defekten Commit wieder rausnehmen und was noch alles. Deswegen wuerd ich schon behaupten, dass das Mergen mit Git einfacher ist und besser funktioniert, als mit jedem anderen VCS zuvor. 

Definitiv _nicht_ sagen wuerde ich, dass Git generell besser ist und man das jetzt ueberall sofort einfuehren muss. Dennoch passiert es derzeit sehr oft.




kama hat gesagt.:


> Hm. in wie fern? Weil es angeblich schneller ist ? oder wie ? Hier geht es um das Branchen/Mergen und das geht mit SVN und Git...



Git ist definitiv viel schneller. Viiiiel schneller. Am Anfang wollte ich gar nicht glauben, dass es wirklich _so_ schnell zwischen den Branches wechseln kann. In diesem Projekt hier (ca 20k Klassen, also schon groesser), dauert das Wechseln zwischen dem ersten Commit im Git (ca. 3 Jahre alt) und dem aktuellsten Stand ca 5 Sekunden. Dabei wird nahezu jede Datei angefasst und geaendert. 

---

* Maven vs Ant

Hier bin ich selbst eher gespalten. Ich persoenlich setz fuer nahezu alle privaten "Gruene-Wiese" Projekte Maven ein. Ich werd mir aber demnaechst definitiv Gradle anschauen, dass buzzt ja grad ziemlich rum.

In einem Projekt hab ich das Buildsystem neu erstellt, nachdem die alten Ant Script unwartbar geworden sind. Nach laengerer Recherche hab ich mich allerdings gegen Maven und fuer Ant mit Ivy entschieden. Die Gruende waren vielfaeltig, das groesste Problem aber war, dass das Projekt bereits aus sehr viel Quellcode ohne grossartige Strukturierung in Module bestand - mit Maven hast du aber immer die Limitierung, dass am Ende nur genau ein Artefakt rauskommen darf. Und in diesem Projekt sind am Ende sehr viele Artefakte entstanden und eine Aufteilung in Module war sogut wie unmoeglich.
Inzwischen kommen eigentlich alle Entwickler ziemlich gut mit dem Ant Zeug klar. Ich hab das aber auch in viele kleinere Ants aufgeteilt, die alle ein Basis-Ant einbinden und fest definierte Targets haben (muessen). Ganz aehnlich also wie bei Maven, aber eben mit der voellen Freiheit, wie alles ablaeuft, funktioniert und aussieht. 

* IDE

Sollte jeder Entwickler selbst entscheiden duerfen. Meine Empfehlung ist IntelliJ IDEA (hat btw auch ne super Android Unterstuetzung, auch in der freien Version). Warum wird eigentlich immer vergessen, das wenigstens mit in die Auswahl zu nehmen?

* JBoss/Glassfish

Ich hab bisher im Java Umfeld nur Erfahrung mit JBoss - und die sind eher schlecht ;-) Das Problem ist dort imho, dass Updates auf neue Versionen ziemlich schwierig sind (vor allem bei aelteren Projekten). Wir haengen immer noch bei einer 4er Version, einfach weil die Umstellung mit extrem viel Arbeit verbunden ist (jaja, das Projekt ist nicht besonders dolle gemacht, aber es ist im produktiven Einsatz und das bereits seit mehreren Jahren).

Glassfish setz ich mit JRuby ein, da gabs bisher gar keine Probleme (ich sag nur "gem install glassfish"). 

Das muss aber rein gar nichts heissen, hier fehlt mir konkrete Erfahrung, um die beiden miteinander vergleichen zu koennen.

* Testing

Ich nehm JUnit, bin damit zufrieden. Fuer Webanwendungen hab ich schon Selenium hergenommen (allerdings fuer ein JRuby Projekt) und war damit recht zufrieden (nachdem das endlich auf dem CI lief... Headless-Mode & Firefox mit Selenium is der Hass ;-) ). 

Man sind das viele Fragen ^^

Edit: Wenn du Git einsetzt, dann unbedingt auch Gerrit ansehen. Das Ding hat unsre Produktivitaet wirklich massiv gesteigert, da es (fast) unmoeglich ist, Build-Breaks zu verursachen. Gerrit ist ein Codereviewtool mit der genialen Eigenschaft, Commits von Teammitgliedern in einer isolierten Umgebung zu bauen und zu testen und erst wenn der Commit korrekt ist, landet er im Master-Branch. Das ist wirklich genial!


----------



## DerFeivel (26. Apr 2012)

schalentier hat gesagt.:


> * JBoss/Glassfish
> 
> Ich hab bisher im Java Umfeld nur Erfahrung mit JBoss - und die sind eher schlecht ;-) Das Problem ist dort imho, dass Updates auf neue Versionen ziemlich schwierig sind (vor allem bei aelteren Projekten). Wir haengen immer noch bei einer 4er Version, einfach weil die Umstellung mit extrem viel Arbeit verbunden ist (jaja, das Projekt ist nicht besonders dolle gemacht, aber es ist im produktiven Einsatz und das bereits seit mehreren Jahren).



True that...:noe:

Besonders erfrischend ist es dann, wenn man nach ner Umstellung mitbekommt, dass man gleich zur nächsten Version weiter darf...


----------



## deetee (26. Apr 2012)

Gradle ist auf jedenfall interessant. Wenn es hält was es verspricht, dann führt eigentlich kein Weg daran vorbei.
IntelliJ IDEA ist für mich nicht interessant, weil ich noch keinen getroffen habe, der es wirklich verwendet hat. Es mag eine gleichwertige IDE sein, aber für meine Bereiche (PHP, Java, Android und Web Mobile) ist Eclipse eine sehr gute Wahl, weil die Plugin Unterstützung oft zuerst für Eclipse auf den Markt kommt, z. B. Phonegap oder auch Blackberry Emulatoren Integration.

Ja, also die Frage nach dem richtigen AS ist für mich auch schwierig, weil mir letztlich die Erfahrung fehlt. Ich finde ja auch Apache Geronimo grundsätzlich interessant, aber ich kenne keine Firma oder Entwickler, die ihn produktiv einsetzen. Daraus schließe ich nicht, dass er nicht produktiv taugt, sondern dass es eben andere AS gibt die etabliert sind und ja letztlich das selbe tun.
Aber naja, wenn man Spring einsetzt könnte sich das Thema AS ja evtl. erledigt haben.

Mit Selenium habe ich auch schon gespielt. Leider aus zeitgründen hat sich Selenium bisher in Projekten nie durchgesetzt. Mal ne Frage, als du Selenium in deine CI Umgebung integriert hast, konntest du dann CrossBrowser Tests damit durchführen? Und wenn ja, wie gut waren die?

JUnit ist auf jedenfall ähnlich wie ANT etabliert und bisher noch Standard. Allerdings ist TestNG doch echt mehr als nur einen Blick wert. Es ist auch nicht komplizierter oder so, im Gegenteil, es ist in den meisten Funktionalitäten gleich zu benutzen wie JUnit. Eine Migration von JUnit Tests ist ebenfalls möglich.

Vielen Dank für den Tipp mit Gerrit. So ein Tool ist echt genial. Allerdings setzt es halt nicht nur Git voraus, sondern auch gewisse Prozesse, z. B. Reviewing und andere QS Maßnahmen. Mal sehen was sich in Zukunft für Möglichkeiten ergeben.


----------



## DerFeivel (26. Apr 2012)

deetee hat gesagt.:


> Aber naja, wenn man Spring einsetzt könnte sich das Thema AS ja evtl. erledigt haben.



Kannst du mir mal bitte erklären, was das eine mit dem anderen zu tun hat? ???:L  (da ich Spring selbst in verschieden ASen benutze, weiß ich schon was es miteinander zu tun hat....daher frag ich mich, warum du den AS weglassen willst)


----------



## deetee (26. Apr 2012)

Spring ermöglicht JEE Features ohne einen AS zu nutzen. Daher ist immer zu anlysieren, inwiefern ein AS noch Sinn macht, wenn man auf Spring setzt.


----------



## deetee (5. Okt 2012)

deetee hat gesagt.:


> Hallo,
> 
> ich bin noch recht neu im JEE Umfeld und bin aktuell am überlegen, wie denn eine zukunftssichere JEE Umgebung aussehen könnte. Fragen die mich beschäftigen:
> 
> ...



So, ein halbes Jahr später hat sich zwar in der Umsetzung nicht viel getan, aber dafür konnte ich ein paar Entscheidungen mehr treffen.

Mit Spring als taktische Entscheidung für die Entwicklung mit Java benötigt man erstmal keinen Application Server, sondern kann mit Tomcat beginnen. Ein Schwergewicht wie Glassfish oder JBoss bringt recht viel Komplexität mit sich und verlangsamt auch häufig den Entwicklungsprozess selbst.

In Sachen ORM habe ich ja totalen Quatsch erzählt. Es stellt sich ja nicht die Frage zwischen JPA oder Hibernate, sondern zwischen Hibernate und EclipseLink oder anderen ORM Frameworks, die den JPA Standard implementieren.

Als Build Management Tool ist Maven auf jedenfall ANT zu bevorzugen. Der Build Prozess inklusive Deployment wird enorm vereinfacht, und darüber hinaus werden durch Maven Plugins Prozesse wie Code Coverage Erzeugung für jedes Projekt und in jeder Phase zum Kinderspiel.

Bei der Frage JUnit oder TestNG fällt die Antwort nicht so deutlich aus. Ich denke JUnit wird noch eine Weile der Platzhirsch bleiben, aber TestNG ist nicht schlechter. Die Frage ist, ob TestNG auch noch die nächsten Jahre sogut weiterentwickelt wird. Ich setze trotzdem auf TestNG, da es mit JUnit Erfahurng ohne Probleme zu benutzen ist und darüber hinaus ein paar nützliche Features mehr bietet.

Als CI Server ist es nun Jenkins, statt Hudson geworden. Apache Continuum habe ich mir leider noch nicht genauer angeschaut.

Und die wahrscheinlich wichtigste Entscheidung ist, dass ich nun endgültig Git, statt Subversion bevorzugen werde. Auch wenn ich noch immer kein Git Experte bin, habe ich mittlerweile soviel praktische Erfahrungen mit Git gesammelt, um zu erkennen, wie unglaublich effizient die Arbeit mit Git ist. Diese Erkenntnis ist hat lange gebraucht, weil ich mich nie wirklich praktisch mit Git beschäftige, weil es mir recht kompliziert erschien. Das Umdenken von Subversion ist das größte Problem und braucht seine Zeit. Aber jetzt bin ich der Meinung, dass Subversion keine Zukunft mehr hat, da Git nicht nur technisch und konzeptionell das bessere Tool ist, sondern es auch effzienteres Arbeiten ermöglicht. Jeder der sich mal 2-4 Wochen mit Git beschäftigt wird das selbst erkennen.


----------



## Marcinek (5. Okt 2012)

deetee hat gesagt.:


> Als CI Server ist es nun Jenkins, statt Hudson geworden. Apache Continuum habe ich mir leider noch nicht genauer angeschaut.



Du hast sich also für die alte Version von Hudson entschieden?


----------



## TheDarkRose (5. Okt 2012)

Marcinek hat gesagt.:


> Du hast sich also für die alte Version von Hudson entschieden?



Alte Version? Jenkins ist ein Nachfolger/Fork von hudson und aktiv in Entwicklung! 

Gesendet von meinem GT-I9000 mit Tapatalk 2


----------



## Marcinek (5. Okt 2012)

Ohh ja, mein Fehler. ^^ Vielleich sollte ich so früh morgens doch nicht so viel posten ;D


----------



## TheDarkRose (5. Okt 2012)

Zuerst den Kaffee aus trinken ^^

Gesendet von meinem GT-I9000 mit Tapatalk 2


----------



## Sym (5. Okt 2012)

deetee hat gesagt.:


> [...]Ein Schwergewicht wie Glassfish oder JBoss bringt recht viel Komplexität mit sich und verlangsamt auch häufig den Entwicklungsprozess selbst.[...]


Der aktuelle JBoss wird als leichtgewichtiger Server benannt. Und ich glaube, das ist er auch. Komplexer als ein Tomcat ist er nicht und schnell ist er ebenfalls.


----------



## deetee (6. Okt 2012)

Ok, das stimmt wohl. Ich habe gerade Tomcat 7.1.1.FINAL und Tomcat7 als Deployment Server in einem Maven Projekt konfiguriert. In diesem Zuge konnte ich auch gleich mal das Maven Cargo Plugin testen.

JBoss 7 startet fast genauso schnell wie Tomcat, das ist schon überraschend. Das Deployment dauert bei beiden gleich lange.

Von daher scheint JBoss 7 tatsächlich ein leichtgewichtiger Application Server zu sein. Danke für den Hinweis.


----------



## KSG9|sebastian (10. Okt 2012)

Auf nen AS zu verzichten und als Begründung "Spring" aufzuführen ist ja schon ein wenig merkwürdig.

Über die Startupzeiten eines Glassfish kann ich absolut nicht klagen..und an einen embedded-Glassfish zur Entwicklung kommt wohl praktisch kein anderer Server dran..auch kein Tomcat.


----------

