Diskussion:Apache Maven

Letzter Kommentar: vor 2 Jahren von ElmarDott in Abschnitt DRY - Don't repeat yourself

Convention over Configuration

Bearbeiten

Hinweis: In der englischsprachigen WP gibt es einen Artikel zum Thema: en:Convention_over_Configuration -- 80.136.59.42 14:00, 2. Mai 2009 (CEST)Beantworten

Beispiele hier deplatziert

Bearbeiten

Ich finde den Beispielabschnitt hier ziemlich unpassend, schon wegen WP:WWNI. In dieser Art und Weise, wäre er wohl besser bei Wikibooks aufgehoben. Es würde reichen allgemein zu erklären, was die Parameter zu bedeuten haben und Schluß. Das hier grenzt schon mehr an ein HowTo. --82.83.81.54 14:33, 10. Dez. 2010 (CET)Beantworten


Neues Softwareprojekt erstellen

Bearbeiten

Im Artikeltext wird angegeben, dass archetype:create benutzt werden soll, um ein neues Projekt anzulegen. Diese Mojo wurde als deprecated markiert (siehe [[1]]), stattdessen sollte jetzt das Generate-Mojo verwendet werden, also archetype:generate. -- White rotten rabbit 12:16, 10. Jan. 2011 (CET)Beantworten

archetype:create nach archetype:generate geändert. -- White rotten rabbit 11:50, 2. Feb. 2011 (CET)Beantworten

"Maven Plugin ermitteln und einsetzen ist Softwareentwicklung"

Bearbeiten

"Die Tätigkeit der mit der Softwareentwicklung betrauten Person beschränkt sich häufig nur darauf, das gewünschte Plugin zu ermitteln und einzusetzen."

Hier fehlt eine Quelle. Außerdem ist der Satz implausibel: Die Installation eines Plugin ist für sich genommen keine Softwareentwicklung. Der Satz müsste zumindest als Zitat gekennzeichnet werden, mit dem Vermerk [sic]. --78.54.25.214 15:38, 6. Mär. 2013 (CET)Beantworten

War missverständlich formuliert. Habs umformuliert - jetzt kann man nicht mehr lesen, dass die Tätigkeit selbst Entwicklung wäre bzw. reicht um Software zu entwickeln. --Sebastian.Dietrich 23:57, 6. Mär. 2013 (CET)Beantworten


Version

Bearbeiten

Aktuelle Version ist 3.6.3 Die Anbindung an Wikidata scheint nicht zu funktionieren? (nicht signierter Beitrag von Jan Hauer (Diskussion | Beiträge) 17:40, 15. Okt. 2020 (CEST))Beantworten

Aktualisierung der Infobox

Bearbeiten

Hallo allerseits

Ich habe mich hier einmal neu angemeldet um mein Wissen zu dem Werkzeug Maven zu teilen. Ich hatte festgestellt das die Übersichtbox mit der aktuellen Version nicht mehr aktuell ist. Leider habe ich nicht herausgefunden, wie man das Ändern kann, da als Werte Platzhalter eingetragen sind.

Ich würde auch gern den Inhalt vervollständigen, da einige Segmente einfach veraltet und auch unvollständig sind. Als Referenz habe ich auch noch meine Diplomarbeit aus dem Jahre 2008 sowie ein Konferenzvortrag der IT-Tage Frankfurt aus 2020 auf deutsch, der die Grundlagen von Maven vorstellt (nicht signierter Beitrag von ElmarDott (Diskussion | Beiträge) 22:03, 23. Dez. 2021 (CET))Beantworten

@ElmarDott: - schön, dass du mithelfen willst. Beachte bitte die Punkte, die die Zusammen/Mitarbeit in der Wikipedia regeln, die jemand so freundlich war auf deiner Diskussionsseite oben hinterlassen hat. Hier nur zu deinen oben genannten Punkten:
  • Die Infobox referenziert mit Platzhaltern auf das zur Seite gehörende Wikidata-Datenobjekt (link darauf in der linken Spalte) - siehe https://www.wikidata.org/wiki/Special:EntityPage/Q139941.
  • Du kannst gerne vervollständigen / aktualisieren - das ist für den Einstieg in die Wikipedia auch sinnvoll, da es hier (wie bei jedem Werk wo viele Leute dran arbeiten) viele Regeln gibt.
  • Gehe auch bitte davon aus, dass alle anderen hier guten Willens sind und auch üblicherweise viel Wissen zu den von ihnen geschriebenen/bearbeiteten Beiträgen haben. Gehe daher davon aus, dass nicht alle deine Änderungen Bestand haben werden und es u.U. zu angeregten Diskussionen in der WP kommt, die aber schlussendlich meist allen Seiten was bringen
  • Beachte bitte, dass bis auf Trivialwissen alles belegt werden muss. Das gilt z.B. auch für einige der Wikidata Einträge (wie das dort geht wirst du dort auch erkennen können) aber insbesondere auch in der eigentlichen Wikipedia. Deine/meine Diplomarbeit ist keine valide Referenz (da du/ich sie geschrieben haben), Diplomarbeiten generieren generell kein neues Wissen, also sind sie darüberhinaus auch generell nicht als Referenz geeignet (siehe WP:Belege). --Sebastian.Dietrich  ✉  19:15, 3. Jan. 2022 (CET)Beantworten
Hallo @Sebastian.Dietrich Danke für den schnellen Kurzeinstieg. Die Menge der Informationen können einem am Anfang schon etwas erschlagen. Ich bin ein wenig verwundert, das wissenschaftliche Arbeiten, zu denen auch Diplomarbeiten zählen nicht als geeignete Referenz gelten. Im Doktorandenseminar haben wir zum Thema korrektes Belegen und Referenzieren von Zitaten in wissenschaftlichen Arbeiten andere Standards gehabt. Da werde ich wohl noch einiges an Zeit aufwenden dürfen, um die hier üblichen Gepflogenheiten zu verinnerlichen.
Ich werde mich mal Stück für Stück durch den "Maven" Artikel arbeiten und freue mich natürlich über Verbesserungs-Hinweise. --https://elmar-dott.com :: Software, Consulting & Training (Diskussion) 19:36, 3. Jan. 2022 (CET)Beantworten
Naja, eine Diplomarbeit ist ja keine wissenschaftliche Arbeit in dem Sinne, dass sie neues Wissen schafft, sondern nur bestehendes Wissen zusammenfasst, prüft etc. Per se ist eine Diplomarbeit nicht als Referenz verboten, aber wirklich geeignet ist sie aus oben genanntem Grund nicht. Schon gar nicht die Diplomarbeit des Autors.
Ich würde dir auch raten deine Signatur zu ändern. Die Wikipedia ist ziemlich allergisch auf (Eigen-)werbung. Bringt dir auch nicht mehr hits, da weblinks alle mit nofollow getagged werden. --Sebastian.Dietrich  ✉  20:07, 3. Jan. 2022 (CET)Beantworten
danke für den tipp - werd das gleich abändern
Hab den "Einführungsteil" einmal erweitert - sobald dieser gesichtet/ korrigiert wurde werd ich mich dann von Abschnitt zu Abschnitt hangeln. Ich denke so wird es dann auch übersichtlicher und leichter nachzuvollziehen, welche Änderungen vorgenommen wurden. --https://elmar-dott.com :: Software, Consulting & Training (Diskussion) 20:58, 3. Jan. 2022 (CET)Beantworten
Klingt schon mal recht gut! Hier ein paar Kritikpunkte, vielleicht kannst sie ja berücksichtigen:
  • Die Einleitung sollte immer kurz gehalten sein - 1 bis max 2 Absätze. Die Absätze 2 und 4 könnten z.B. im Abschnitt Konzeptionelles stehen.
  • Wenn du schon schreibst "in der offiziellen Dokumentation..." dann könntest auch gleich eine Referenz darauf angeben. Am besten gleich mittels ref und Vorlage:Internetquelle Kopiervorlage
  • Wenn du schreibst "sehr kompakt gehalten", dann klingt das ein wenig nach Werbung. Wie kompakt ist denn "sehr kompakt"? Besser wäre z.B. das gar nicht zu schreiben (modular reicht mMn) oder "wurde versucht kompakt zu halten" inkl. einem Beleg für dieses Ziel.
  • Generell versuche alles nicht-triviale zu belegen. z.B. dass es in IDEs enthalten ist, dass die Funktionen über central nachgeladen werden, dass man selbst plugins schreiben kann, dass es "plugin execution framework" genannt wird. Also wirklich alles. Wennst keine Belege findest/hast, dann ists nicht tragisch (gelöscht wirds nur, wenn wer das anzweifelt), aber du solltest dir überlegen, woher du das hast und ob du dir auch sicher bist.
Aber alles nix tragisches - nur weiter so :-) --Sebastian.Dietrich  ✉  20:25, 4. Jan. 2022 (CET)Beantworten
Danke Danke :-)
Das mit den Quellen ist im Moment noch ein technisches Problem - ich versuche momentan die Werkzeuge zu verstehen :-)
Mein Konzept ist es den original Artikel Stück für Stück zu überarbeiten und ein wenig einen roten faden hineinzubringen. Meine und die Arbeitsweise vieler Kollegen ist in der Einleitung einen Überblick zu erhalten und dann Schritt für Schritt in die Details einzutauchen. Natürlich gilt es auch daran zu denken das der fertige Artikel dann kein Buch ist ;-) Viele der Dinge die ich hier erwähne kommen direkt von den Entwicklern, offiziellen Mailing Listen, Konferenzvorträgen, Büchern etc. Ich denke wenn ich mit allen Teilen durch bin ist das dann erst mal Iteration 1, wo dann "umgangssprachliche" Ausdrücke gegen neutrale Formulierungen ausgetauscht werden und ggf Kürzungen vorgenommen werden müssen. Mal schauen, wie lange ich brauche bis alles rund ist. Auf jeden Fall eine spannende Erfahrung und völlig anders als die von mir veröffentlichten Artikel in den üblichen Magazinen. -- Elmar Dott: Build-, Configuration- & Release-Management (Diskussion) 00:53, 5. Jan. 2022 (CET)Beantworten
Ja klar. Artikel für Fachzeitschriften schreibt man erstmal selbst und erst dann kommt die Redaktion bzw. das Peer-Review und erst danach die Veröffentlichung. Hier läufts aber (wie bei Wikis üblich) anders: Der Artikel ist von Anfang an veröffentlicht und sollte daher immer passabel sein. Die Erweiterungen erfolgen eher inkrementell und weniger iterativ. Darum schreibt man einen neuen Artikel zunächst mal in seinem eigenen Benutzernamensraum und verschiebt ihn erst ab dem Zeitpunkt wo er halbwegs passt in den allgemeinen Namensraum. Das ist aber hier nicht der Fall und auch nicht nötig. Nachdem das Lemma ein nicht so umstrittenes bzw. aktuelles ist, wird hier auch der iterative Ansatz funktionieren. Aber wenn du z.B. in SARS-CoV-2-Variante Omikron oder Homöopathie was schreibst, wird das nicht funktionieren.
Zur Einleitung gibt es in der WP Vorgaben, die tw. anders als bei Fachzeitschriften sind. Siehe WP:INTRO --Sebastian.Dietrich  ✉  18:44, 5. Jan. 2022 (CET)Beantworten

DRY - Don't repeat yourself

Bearbeiten

Die aussage in Konzeptionelles zu DRY:

  "Maven dass nicht bei jedem Projekt dieselben Build-Schritte neu definiert werden müssen."

Ist zwar grundsätzlich nicht verkehrt und wird auch oft zur Erklärung herangezogen. Die Intension war aber eine völlig andere.

Als man vor Maven mit Ant arbeitete gab es keine festen Verzeichnisstrukturen viele Projekte hatten ein Verzeichnis für die Sourcen, meist src benannt, ein Verzeichnis für Tests das auch Tests hieß und ein Verzeichnis namens libs für 3rd party libraries (z.B. log4J) - da Enterprise Projekte etwas umfangreicher und manchmal auch komplexer sind und weitaus größerer Strukturen benötigten, machte hier jeder wie man meinte das es passt. Das ist natürlich problematisch für Leute die neu ins Projekt kommen - die brauchen meist ein wenig Zeit und oft auch Unterstützung von erfahrenen Teammitgliedern sich im Projekt zurechtzufinden. Daher kommt auch die Aussage das zeitkritische Projekte nicht mit doppelt so vielen Personen doppelt so schnell durchgeführt werden können. Neben der extremen Vereinfachung des Dependency Managements war der zweite wichtige "Standard" den Maven gesetzt hat die feste Verzeichnisstruktur. Dinge die vom Nachfolger Gradle nicht umsonst übernommen wurden. Grade in der Zeit um 2009, als viele Unternehmen Ihre alten Build Infrastrukturen auf Maven migrieren wollten, entstand extrem viel Frustration, weil man versuchte Maven an die vorhandene Projektstrukturen anzupassen (was zwar grundsätzlich funktioniert, aber in vielen Details später zu Problemen führte), anstatt diese Strukturen dem Maven-Standard anzupassen. Man scheute die Zeit-Investition das Projekt entsprechend umzubauen, weil man sich nicht sicher war, ob Maven die Erwartungen des Unternehmens erfüllen wird. Als man bemerkte, das es gut funktionierte sah man keine Notwendigkeit eine echte "Refaktorierung" durchzuführen und bekam schnell Probleme als neue Werkzeuge wie Repository Manager, Code Instrumentation & Inspektion, CI /CD Build Pipelines etc. einführen wollte.

Ja die Erklärung ist ein wenig lang für ein Lexikon :-) vielleicht finden wir etwas kompakteres, das wir bei DRY anfügen können. Ich mach erstmal mit den Konzepten weiter und würde auch die Diskussion über die Beispiele wieder aufgreifen wollen. Ich gehöre zu der Gruppe die der Meinung ist das die Beispiele besser in einem WIKI Book aufgehoben sind und nur an den Stellen eingestreut werden sollten, wo sie die Erklärung 'vereinfachen' - bzw. den Nebel lüften. -- Elmar Dott: Build-, Configuration- & Release-Management (Diskussion) 16:21, 11. Jan. 2022 (CET)Beantworten

Ich sehe das genauso wie du (auch dass das zu viel wäre für die WP). Aber: Die gleichartige Verzeichnisstruktur passt nicht zu DRY, weil damit keine Verdopplungen vermieden oder verhindert werden. Gleichartige Verzeichnisstruktur passt zu CoC, da man sich damit erspart zu sagen, wo sich die Sourcen befinden, wo die Binaries hingespielt werden müssen etc.
Nachdem du den Absatz zu DRY (zu dem schon vorhandenen Absatz zu CoC) geschrieben hast, dachte ich, dass DRY (so wie du es geschrieben hast) ein bewusst gewähltes Paradigma von Maven wäre (und es dafür auch wo Belege gäbe). Nachdem aber die Verzeichnisstruktur nicht zu DRY passt, hab ich etwas von Maven geschrieben, das sehr wohl zu DRY passt.
D.h. entweder wir belegen das mit dem DRY (und idealerweise auch was die Maven Leute als Beispiel für DRY angesehen haben), oder wir nehmen den Absatz wieder raus und sprechen wie früher nur von einem Paradigma.
P.S: hinsichtlich der Beispiele bin ich deiner Meinung. Die sind so trivial, dass sie kaum was bringen. Sie müssten ausgebaut und aktualisiert werden (pmd oder site macht vermutlich heute kaum wer mehr, da gibts weitaus besseres) und besser in ein Wiki Book verschoben werden. Aber auch hier ist der Nutzen recht gering. --Sebastian.Dietrich  ✉  17:38, 11. Jan. 2022 (CET)Beantworten
Ich hab das einmal umgebaut - ich hoffe es zerhaut die Formatierung der verzeichnistruktur nicht - falls das probleme macht könnten wir das auch als grafik einbinden - dann stresst das mit den Einrückungen nicht sosehr und man kann es hoffentlich besser lesen. Ich hab auch ein paar 'veraltete' links entfernt PHP 4 Maven wird seit jahren nicht mehr contributed - war da selbst minimal mit daran beteiligt, daher kann ich definitiv sagen das ist momentan tot und müsste für PHP 7/8 angepasst werden.
Das Thema DRY werd ich später noch einmal aufgreifen wenn ich in den Tonnen meiner Unterlagen refernzfähige Verweise gefunden habe. Das sichten ist momentan etwas vor dem es mich graut *zwinker* Aber ich denke wir haben schon echt viel geschafft und der Artikel wird von den Infos her besser und auch wieder aktueller.
Ich glaube der Abschnitt mit den Entwicklungsumgebungen kann gestrichen werden, wir haben ja bereits erwähnt das eclipse netbeans etc das out of the box schon mitbringt. Und aus eigener erfahrung kann ich sagen das die lösung von eclipse nicht so der große wurf geworden ist, dafür NetBeans mit der Maven Integration richtig gute Arbeit geleistet hat. laut meiner Erfahrung artet eine Unterhaltung über IDE oft in 'Glaubenskriegen' aus - wie die frage über die richtige Programmiersprache. Deswegen sollten wir das besser vermeiden. Reduziert das risiko von Edit wars und Vandalismus :-) ansosnten muss ich noch würfel was zuerst besser ist lifecycle oder dependency management ... -- Elmar Dott: Build-, Configuration- & Release-Management (Diskussion) 20:00, 12. Jan. 2022 (CET)Beantworten
Das mit der Verzeichnisstruktur passt nicht (der Rest mMn schon) - ich habe aber jetzt auch nichts gefunden, mit dem man eine Verzeichnisstruktur in der WP hübsch darstellen kann. D.h. wir werden (asap) eine Grafik brauchen...
Die Referenzen solltest besser nicht erst im Nachhinein reingeben. Nicht Belegtes kann in der WP jederzeit gelöscht werden, oft kommt man erst beim Nachlesen der Referenzen drauf, dass das, was man geschrieben hat, so gar nicht stimmt und oft vergisst man dann im Nachhinein die Referenzen reinzugeben. --Sebastian.Dietrich  ✉  07:04, 13. Jan. 2022 (CET)Beantworten
ich habe ein screenshot gemacht - kann die datei aber nicht hochladen, weil sie nicht durch die Prüfung kommt.
Ich hab Sie mal auf meinem Server abgelegt - hier die URL (temporär): https://elmar-dott.com/wp-content/uploads/Screenshot_Maven-dirstructure.jpg
Sobald die Datei erfolgreich hier hochgeladen & eingebunden ist werd ich sie wieder bei mir löschen. -- Elmar Dott: Build-, Configuration- & Release-Management (Diskussion) 18:24, 15. Jan. 2022 (CET)Beantworten