Prinzipiell sollte man sich an der von maven definierten Projektstruktur orientieren. Demnach beginnt unterhalb von src/main/java die Ordnerstruktur der Java-Packages.
Deine Java-Klassen solltest Du nach Aufgabengebieten ordnen und Klassen, die sich mit der selben (oder einer ähnlichen) Aufgabe beschäftigen in Packages zusammenfassen.
Wenn Du feststellst, dass Du Klassen hast, die Du in mehreren Projekten verwenden könntest zuögere nicht, daraus ein eigenes Eclipse-Projekt zu machen. In Eclipse können Projekte von einander abhängenen, so dass die Anwendung das trotsdem alle Java-Klassen zur Verfügung hat.
Auf jedenfall Maven lernen, dann hast du Organisation und Struktur für deine Sourcen inkl. Testklassen, aber auch das Dependency Management für fremde JARs.
Herzlichen Dank für die ausführlichen Antworten !
Ich habe mir mal das Maven angesehen (Eher überflogen) bin aber der Meinung, das ich mich mit diesem Thema mal mehr beschäftige.
Dokumentationen und Tutorials gibt es ja genug im Netz.
Also es gibt auch Maven Projekte, bei denen die Struktur anders ist (z.B. Maven Tycho)
Wenn man OSGi Bundles entwickelt gibts es auch schon ein “Best practice”.
Von dem her ist es schwer deine Frage zu beantworten, es kommt auf deine Anwendung ein…
Das ist Geschmackssache. Ganz hardcore ist es Build-Scripte mit Bash (oder ähnlichem) zu machen. Irgendwo zwischen Bash und Maven liegt Ant. Maven nimmt Dir viele Kleinigkeiten ab, wenn Du Dich an die Struktur hälst. Bei Ant und bash musst Du alles selber machen - hast dafür mehr Flexibilität. Ich bin bei Bash und Ant hängen geblieben.
Bei den Packages experimentiere ich gerade ein bischen, aber prinzipiell:
+ TLD
+ Domain
+ Projekt
+ Teilprojekt1
+ Teilprojekt2
+ TeilprojektX
+ model
+ view
+ controler
[QUOTE=mogel]Ich bin bei Bash und Ant hängen geblieben.[/QUOTE]Selbst schuld… ;o)
Die Behandlung indirekter Abhängigkeiten durch maven möchte ich nicht mehr missen…
Ich halte das für den professionellen Bereich kaum machbar. Gerade wenn man mit mehreren Leuten an Projekten arbeitet, zahlt es sich aus, Standards zu nutzen.
Natürlich kann man sich selbst eine Struktur aufbauen, aber warum, wenn sich andere genau darüber mehr als genug Gedanken gemacht haben? Und warum sollte ich den Aufwand jedes mal in Kauf nehmen, Bash- und Ant-Skripte zu bauen, wenn es mit Maven oder Gradle doch so viel einfacher ist?
[QUOTE=Timothy_Truckle;69379]Selbst schuld… ;o)
Die Behandlung indirekter Abhängigkeiten durch maven möchte ich nicht mehr missen…[/QUOTE]
Damit bin ich bei C++ & Co schon wieder außen vor. Make ist mir selber zu nervig um alles damit abzubilden. Dazu kommen noch Spezial-Build-Tools von Analog-Devices die über eine „TCP-Brücke“ an den gesamten Build angeschlossen sind. Ich habe also keine wirkliche Notwendigkeit mich in Maven einzuarbeiten, da ich nicht nur Java mache. Das was ich mit Java mache, kann mit auch Ant sauber erstellen.
Es macht trotzdem Sinn sich an die Maven Ordnerstruktur zu halten, auch wenn man in einer Sprache programmiert, die kein Maven Support hat. Der Grund ist, dass die Maven Struktur einfach logisch aufgebaut ist, z.B. haben Unit Tests und sogar Integration Tests ihren festen Platz. Man muss sich nur mal mit dieser Ordnerstruktur befassen, damit man den Zweck dahinter versteht.
Meine PHP Kollegen tun sich sehr schwer diese src/main/php, src/test/php Struktur zu akzeptieren bzw. zu verstehen, weil sie sich damit nicht genug auseinandergesetzt haben. Stattdessen kommt jeder mit einer eigenen Idee einer Ordnersturktur…absolut sinnlos. Und dabei gibt es sogar http://www.php-maven.org, was zeigt, dass Maven auch schon in die PHP Welt eingezogen ist.
Genauso wie das Maven Dependency Management auch mit Composer und Konsorten in die PHP Welt portiert wurde. Auch da hat der ein oder andere PHP Entwickler kein Bock drauf gehabt, ging ja schließlich auch vorher ohne.
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.
[QUOTE=deetee]Es macht trotzdem Sinn sich an die Maven Ordnerstruktur zu halten, auch wenn man in einer Sprache programmiert, die kein Maven Support hat. Der Grund ist, dass die Maven Struktur einfach logisch aufgebaut ist, z.B. haben Unit Tests und sogar Integration Tests ihren festen Platz. Man muss sich nur mal mit dieser Ordnerstruktur befassen, damit man den Zweck dahinter versteht.
[/QUOTE]
Es gibt wie oben genannt auch Gründe sich nicht daran zu halten, darum würde ich hier nicht alles über einen Kamm scheren. Zusätzlich gibt es auch Technologien die sich schon lange über das Dependency Management Gedanken gemacht haben und da ist es anders gelöst wie auf “nur” auf jar Ebene und nicht in der pom --> OSGi.
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.
Genau das ist der Grund wieso ich gerne einen Bogen um „High-Level“ Buildtools mache. Je mehr die einem die Arbeit abnehmen, um so schwieriger wird es individuelle Probleme damit zu lösen. Außerdem:
Warum jedesmal das Rad neu erfinden? Weil es irgend wann mal besser ist oder keiner mehr weis wie es geht
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…
Die Idee ist nicht nur nett, sondern sehr gut durchdacht und verbreitet sich auch langsam siehe Glashfish und JBoss…
Versteh ich jetzt nicht was genau ist problematisch?
Problem #1 war, dass WebLogic OSGi offiziell erst ab der 12er Version unterstützt, die in der Firma erst nächstes Jahr kommt. Problem #2 war, und ist meines Wissens immer noch, dass es diverse Classloading Probleme gibt, wenn ich im WebLogic einen Call zu einem Service mache, der im CICS deployed ist. Zu diesem Thema stehen wir auch in Kontakt mit IBM, die immer mal wieder ein paar Workarounds reinschmeißen.
Da ich allerdings momentan im Studienquartal bin, kenne ich den aktuellen Stand nicht. (Es zählte auch sowieso nicht zu meinen primären Aufgaben, ich hab nur getestet, rumgespielt und geguckt, was ich zum Laufen bekomme)
Dass das ein Spezialfall ist weiß ich selber, aber wie sagt man so schön: Der erste Eindruck zählt, und daher ist leider OSGi schon etwas negativ bei mir konnotiert
Keine Ahnung was WebLogic und keine Ahnung was ihr macht, aber wenn ihr was verbockt kann doch OSGi nix dafür…
Ist genauso wie das gelaber Swing ist langsam, SWT ist langsam, JavaFX kann nix und es lebe nur noch HTML5 …
Egal was es ist, wenn man es falsch macht sollte man es nicht auf andere Dinge schieben…
