Warum benutzen so wenige Leute Maven? Gibt es alternative Tools?
Ich bin neu in Java, und als ich begann, meine Entwicklung, meine Freunde empfohlen Maven für das Projekt-management. Ich fast sofort klar, dass es ist ein unverzichtbares Werkzeug, und damals dachte ich, dass alle Programmierer verwenden es. Aber wenn ich unter Statistiken auf der NetBeans-Website, war ich im Schock: 67% der Entwickler sind nicht mit Maven. Warum? Gibt es alternative tools zum Projekt management einfach?
UPDATE
Ich Stimme mit feicipet auf 100%.
- IDE-unabhängigen, es ist wirklich gut. Dies wurde bewiesen, die auf meinen eigenen Erfahrungen. Erstens, unser team verwendet die Eclipse, dann haben wir beschlossen zu wechseln, NetBeans, die Menschen, die uns helfen mit das Projekt mit der IDEE. Und es spielt keine Rolle, weil das Projekt ausgeführt werden kann auch mit der Konsole:)
- Gut strukturiert und clean-Projekt. Ich denke, Maven-Struktur-übereinkommen ist sehr hilfreich, da tests und Haupt-code getrennt sind.
- Projekt-management. Maven-es ist nicht nur build-tooles geben Ihnen die Möglichkeit, konfigurieren Sie die Umgebung, unit-tests, und Berichte erstellen.
Für mich, es drehte sich überrascht, als der erfahrene Programmier-sprechen über die Schwierigkeiten von Maven, als ich sah, Ant-in einem Projekt Maven zeigte mir ein Wunder. Und alle Kommentare über die Komplexität des übergangs von der Ameise sind seltsam. Dies sind zwei unterschiedliche Logik, was erwartest du?
Gibt es einige Probleme mit der Dokumentation, das ist wirklich schlimm. Aber ich denke, diese situation zum besseren zu verändern
InformationsquelleAutor der Frage |
Du musst angemeldet sein, um einen Kommentar abzugeben.
Gibt es eine Menge alternativen - in der java und der ruby-community. Für eine übersicht schauen dieses Bild
InformationsquelleAutor der Antwort
IMO Maven ist ein over-engineered Rube-Goldberg-Maschineoder in den Worten von Graeme Rocher (Grails project lead), "die EJB2 von build-tools".
Ich denke, die Ziele des Maven-Projekt sind sehr würdig. Convention over configuration? Super!!! Automatische Auflösung von Abhängigkeiten? Super! Aber leider ist die Praxis sehr anders aus als die Theorie. In meiner Erfahrung ist die Einführung von Maven-Projekten wurden bisher gebaut mit Ant hat immer mehr Probleme geschaffen als gelöst. In einem Fall Maven gestartet zu nehmen so viel von unserer Zeit, dass wir uns irgendwann migriert zurück zur Ameise wieder.
Ich denke, Maven Wert sein könnte, die Schmerzen, wenn Sie eine große Anzahl von Projekten, die alle voneinander abhängen, und die Entwicklung ist weit verbreitet. Aber wenn Sie eine einzelne Anwendung aus, und wollen einfach nur zu tun, etwas einfaches wie "Baue eine KRIEG von den Zeug in diese Verzeichnisse", dann würde ich laufen eine Meile von Maven.
Ein problem ich hab encoutered mit Maven ist, dass es eigentlich ziemlich unflexibel, wenn Sie brauchen, etwas zu tun, das läuft im Gegensatz zu Maven - Konventionen. Obwohl Sie außer Kraft setzen können, diese Konventionen in einigen trivialen Fällen (z.B. ändern Sie den Namen der Quell-Ordner, von
srczusource), einige Konventionen scheinen in Stein gemeißelt, z.B. ein Artefakt pro Projekt. Nehmen wir beispielsweise Maven, web-Projekt, dessen Artefakt ist .war-Datei. Nun Stell dir vor, wir würden gerne mal die aktuelle SVN-revision-Nummer in der .Krieg mit dem Namen. Dies scheint nicht, wie es sein sollte, besonders schwierig zu erreichen, aber es sei denn du findest ein plugin, dass bereits dies tut, werden Sie wahrscheinlich haben, um schreiben Sie Ihre eigenen plugins, um es zu erreichen, das ist keine triviale Aufgabe, da es erfordert, dass Sie verstehen, Maven Modell der Lebenszyklen und Ziele.Zur Beantwortung des zweiten Teils Ihrer Frage nach alternativen: ich habe nicht verwendet es nicht persönlich, aber habe gehört sehr gute Dinge über Gradle. Eine Reihe von high-profile-JVM-Projekte wie Spring und Hibernate, die zuvor gebaut mit Maven habe vor kurzem wechselte zu Gradle.
InformationsquelleAutor der Antwort
Mag ich Maven und verwenden Sie es fast ausschließlich in meiner Firma. Aber ich würde es rechtfertigen, meine Gründe dafür:
brauchen Struktur. Ich brauche die meisten meiner
Entwickler Folgen einem bestimmten Satz
von Konventionen hinunter zum Projekt
layouts. Dies ist, um es einfacher zu machen
für übergaben, wenn Verschleiß Auftritt.
Segen in dieser Hinsicht. Die Senioren
würde nur bestimmte
Archetypen für bestimmte Projekt
Vorlagen, die alle Entwickler nur
als Basis für Ihre Projekte auf. Es gibt eine
wirklich einfache generische für diejenigen, die eine
Fälle, in denen wir nicht geschafft haben
gerecht für. Check-out eine ant-basierte
layout von SVN ist weniger intuitiv in
dieser Hinsicht als die Entwickler
immer noch müssen, entfernen Sie die ursprüngliche
.svnMetadaten, sobald es überprüft.
Ich will nicht zu Basis jeder meiner
Einstellungspolitik auf, was die IDE
Entwickler bevorzugt zu verwenden. Mindestens 2
große IDEs (Eclipse und NetBeans)
haben ziemlich gute integration zu
Maven schon so, dass ein
pom.xmlDatei bereits die definition
ein IDE-Projekt. Ich kann sagen, alle
neue Entwickler, die er einsetzen kann
was auch immer IDE er bevorzugt, solange
das build-system selbst basiert auf
Maven.
bootstrap-Prozess für die Abholung
Dinge, die midway war drastisch reduziert
unten, wenn ich wechselte zu Maven. Neue
Entwickler, auch diejenigen, die nicht
mit dem Projekt an der hand, war in der Lage
zumindest kompilieren, Verpacken und
Bereitstellung innerhalb von einer halben Stunde briefing
Ihnen von dem Projekt. Support-Mitarbeiter
(die sind in der Regel nicht so
technisch versiert) konnten
konzentrieren Sie sich auf Fehlersuche und
nicht ärgern über das Projekt zu erstellen,
das ist eine unnötige Reizung.
Alles in allem, Maven passt meine Bedürfnisse perfekt. Ich Stimme zu einem gewissen Grad, dass ein Unabhängiger Entwickler, hat seinen eigenen workflow-und Projekt-management-Praktiken können nicht hergeleitet werden viel davon profitieren, aber keiner von uns hier arbeiten, in eine leere, durch uns selbst.
InformationsquelleAutor der Antwort
Einer Menge von Maven-Griffe, die ich angetroffen habe, sind aufgeführt und beantwortet in diesem blog Eintrag. Meine Erfahrung ist, dass die java-Entwickler haben die volle Kontrolle über Ihre Projekte. Viele der Gründe, die Sie gegen Maven sind im Grunde "es ist nicht ant" oder ich kann das nicht X wie kann ich in der Ameise".
Gibt es sicherlich einige gültige Koliken. Die Dokumentation ist oft eine bemitleidenswerte, die Lernkurve kann steil sein, und die Konfiguration ist ausführlich. Weil so viel Konvention beteiligt ist, wenn etwas schief geht, es kann sehr hart sein, um festzustellen, ob es dein Fehler oder ein feature/bug in einem plugin.
So gegeben, das negative, ist es verständlich, dass die Menschen würden nicht das geringste zu investieren Zeit und Mühe in ein build-tool, wenn Sie können, gehen mit, was Sie wissen (ant/machen/was auch immer) und wieder mit "doing the job", nachdem Sie alle Ihre Kunden, egal, wie sexy Sie Ihren build-Prozess ist.
InformationsquelleAutor der Antwort
Nach der Migration zu viele Projekte auf maven (angefangen von reinen java zu reinen javascript und xslt-Projekte) ich denke, Vorteile:Nachteile der Verwendung von maven sind 50:50. Die wichtigsten Nachteile sind:
<copy from="" to=""/>oder registrieren mvn plugin und geben Sie Tonnen von Eigenschaften?InformationsquelleAutor der Antwort
Ich denke, Maven leidet unter einer relativ hohen Einstiegshürde im Vergleich zu tools wie Ant. Die Schwierigkeiten, die mit früheren Versionen und die Komplexität von 2,0 gehalten haben mich Weg. Es ist nicht 100% nötig, vor allem, wenn Sie eine gute IDE.
InformationsquelleAutor der Antwort
Für ein Alternatives tool, ich biete Gradle. Es baut auf Ant und Maven und unterstützt alle standard-Ziele (compilieren, unit tests, etc.). Der wichtigste Vorteil ist, dass die Konfiguration wird in Groovy, die für Flüssigkeit, prägnante Dateien. (Das heißt, man wird lernen müssen, groovig, zum Teil).
Der entscheidende Punkt ist, dass es eine falsche Dichotomie, Grube Ameise-Efeu versus Maven, wie es viele tun. Gebloggt habe ich über dieses hier. (Beachten Sie, dass seit dem blog-post, Gradle abgelöst hat Gant als Allgemeine build-tool.)
InformationsquelleAutor der Antwort
Maven können definitiv einen Krampf in Ihrem Stil. Ich wechselte ein ant-build über maven, denn ich hatte eine ganze Reihe von Projekten mit gegenseitigen Abhängigkeiten. Bekam ich die bauen werde, aber ich weiß noch nicht, fühle mich als hätte ich meinen Kopf um das Tier.
Viele das problem kommt auf die Dokumentation. Die kanonische guide ist oft ein forum-post oder stackoverflow-Antwort auf ein ganz anderes problem, dass Sie nur zufällig auf.
Wie diese Anleitung zur Verwendung-cargo: Starten von externen Prozess während der Integrationstests im mavendie ich gefunden habe nicht aus dem maven-cargo-plugin-website, aber nur, weil ich zufällig Troll durch stackoverflow.
Aber wenn man das mojo, und dann die Fracht-Seite, ist es wirklich verständlich wird der Durchschnitt (read me) developer?
Vielleicht maven ist wie der Kapitalismus, es ist der schlechteste mit Ausnahme für alles andere.
InformationsquelleAutor der Antwort
Sieht alles glänzend, wenn Sie etwas neues lernen und mit der richtigen Einführung, Maven (oder jedem Werkzeug, das für diese Angelegenheit) sieht toll aus. Wenn Sie etwas haben, das bereits in der Existenz, und möglicherweise unvollkommene, nämlich eine vorhandene nicht-Maven Projekt, das versucht zu Schuh-horn Maven auf es ist ein PITA.
Google so sagt. Ant, Gradle, Gant, Efeu, Rake, SBT. Ich persönlich zugunsten Gradle und Gant über alles andere. SBT kann ein Schwein, aber sobald man es läuft, ist es süß. Und ich würde über Ant Maven für alle neuen oder bestehenden Projekt.
Versteh mich nicht falsch, ich habe Maven, und ich kann mich beherrschen. Das problem ist, dass es wirklich eine Schublade stecken Dinge mit seinem plug-in-Architektur. Versuchen Sie etwas, das out-of-the-box, und es wird eine schmutzige Aufgabe.
Vielleicht die erfahrenen Programmierer sind auf etwas. IMO, zu verstehen, Maven, müssen Sie zunächst verstehen, Ant, und was Maven versucht, oder versucht zu lösen.
Ant
Ant ist angesichts der schlechten Ruf, weil die meisten Menschen sind beschissen Programmierer, nehmen Sie und Ihre miese Praktiken bei der Erstellung Ihrer Ant-build-Systeme.
Schlechte Programmierer Folgendes tun:
Sie entweder über-die Dinge zu vereinfachen, und erstellen Sie Systeme erstellen, die nicht mit Veränderungen umzugehen, die in das Projekt (jeden realen komplexen system Erfahrungen änderungen)
oder Sie über-die Dinge zu komplizieren, indem er einen schwarzen Wald, dunkle Armee von ant-builds verteilt über den Platz, ohne zusammenhängende Gedanken hinter Ihnen. Dies ist normalerweise das Ergebnis von fehlgeleiteten Bemühungen, de-Kupplung, die tatsächlich in dem, was ich nennen verteilt uber-Kopplung: alles hängt mit allem zusammen zu arbeiten, auch ohne jegliche Zusicherung, die Sie tun.
Ant ziemlich viel folgt einem Modell namens GIGO: Garbage In, Garbage Out. Sie müssen erhebliche Vorüberlegungen, wenn Sie Ihre Ant-Skripten.
Dies ist nicht ein problem für einen guten Entwickler. Leider, für die LKW-Ladung bad-Entwickler erstellen Sie diese Monstrositäten und die Schuld des Tools. Es ist, wie wenn man mit dem Arsch auf dem grill und die Schuld es für burning man.
Maven
Geben Sie Maven. Es versucht zu lösen, die uber-Komplexität monster durch die Bereitstellung von Projekt-Skelette und bauen Gerüste. Was Maven-Archetypen nennt. Rufen Sie Maven erstellen eines neuen Projekts mit der maven-archetype-webapp Archetyp, und voila, es baut ein komplettes Projekt-Gerüst für Ihre, einschließlich directory-Struktur, deployment-Deskriptoren und was nicht.
Aber was passiert, wenn Sie ein vorhandenes system, das nicht unbedingt die Einhaltung der Archetyp? Was passiert, wenn Sie wollen, oder Sie benötigen ein anderes layout?
Gibt es Lösungen (.ie erstellen Sie Ihre eigenen Archetyp), aber die Dinge nicht bekommen, die einfach nicht mehr. Dann gibt es das ganze Problem von einem repository. Viele Male, können Sie einfach den Standard-repositories und ziehen Sie, was Sie brauchen, über den Draht.
Zu anderen Zeiten Sie einfach nicht und dann treten wir in die Bereiche der Logistik. Worauf legen Sie Ihr repository? Sie haben eine für das gesamte Unternehmen oder für verschiedene Projekte haben Ihre eigenen (aufgrund von rechtlichen oder geografischen Anforderungen)? Haben Sie die version den Inhalt des Repositorys oder mehrerer Repositorys?
Wenn ja, was passiert, wenn Sie rechtlich/vertraglich verpflichtet, ein source-control-repository wie ClearCase, wo Sie explizit überprüfen Sie die Dinge aus, bevor Sie eine Veränderung? Dümmliche Logistische Dinge, die sollten nicht kommen sogar in die Bild-und Entwickler' Geist beginnen zu kriechen.
Gibt es praktische (ebenso dummen) Gründen zu bevorzugen, die über Ant Maven und Umgekehrt. Es ist einfach so passiert, dass die split zufällig um 1/3 zugunsten der Maven 2/3 Begünstigung Ant. Die split ähnelt der ratio, die ich gesehen habe von from-scratch neuen Projekte und bestehenden.
Ein weiterer Grund zu vermeiden (oder zumindest Objektive zweite Meinung) Maven ist in Bezug auf seine Dokumentation. Es hat sich etwas verbessert, aber es verwendet, um zu saugen. Das führt zu einem logistischen problem. Wenn ich ein hiring manager, die ich beachten muss einige der Instrumente, um ein breiteres Fachpublikum.
Es ist einfach so passiert, es gibt weit mehr Ant-aware-Entwickler (gute und schlechte) als Maven-Entwickler (gute und schlechte.) Dies ist etwas, was ich nehmen würde in eine ernsthafte Betrachtung.
Wieder, ich habe in Maven-Projekten, und ich habe keine Probleme, es zu benutzen für konventionelle und benutzerdefinierte Archetypen. Ich habe gerade eher nicht. Vielleicht ist meine Brille gefärbt für die verwendeten Ant-viel mehr (doppelt so viele Jahre eigentlich).
Mit dieser sagte, ich würde verwenden, Gradle für ein neues system (oder schreiben Sie ein Ant-oder Maven-build-system hinein, wenn ich die Vollmacht hatte, und die Entwickler um mich herum waren halb-kompetent zumindest.)
Es ist einfach ein superior-build-system im Vergleich zu Ant und Maven.
InformationsquelleAutor der Antwort
Wie gesagt, es ist eine hohe Barriere für die Einreise. Es gibt auch Tonnen von alten Projekten, die bereits über gut etablierte build-Skripte/tools - es macht keinen Sinn, in den meisten Fällen zu ersetzen, etwas, das funktioniert bereits mit maven.
Fehlende/verstreut Dokumentation nicht helfen - das einzige, wirklich gute Tutorials für maven ist ein in voller Länge Buch, geschrieben von sonatype... und das ist schon viel, jemanden zu bitten, zu Lesen und gehen Sie dann lernen, wie die plugins funktionieren alle, die für den alleinigen Zweck zu bauen/verwalten pom.xml um zu definieren, wie ein Projekt gebaut wird/geschafft.
Mit, sagte aber, maven ist ein tolles tool (wenn auch ein bisschen zu Komplex für seine eigenen gut).
InformationsquelleAutor der Antwort
Arbeite ich auf großen Entwicklungs-Projekte mit mehreren teams in verschiedenen Regionen tätig. Ich habe eine Ausführung eines maven paar mal und jetzt nach ein paar Tagen zu Frust total, jedes mal wenn ich es versuche, ich habe das werfen meine Hände in die Luft und aufgeben. Kann ich einfach Ant-Makros, die Abhängigkeiten überprüft in Quell-repository.
Sicher, ich würde eher verwenden, maven, aber es ist einfach zu schwierig, um aus dem Boden.
Der Rechner war ein großer Fortschritt, über den Rechenschieber, weil es einfacher war, zu verwenden (zusätzlich zu der Möglichkeit, mehr Probleme zu lösen). Während maven kann einige Probleme lösen, es schafft auch Probleme auf eigene (vor allem einfache Aufgaben viel schwieriger ist --- vor allem, schwieriger zu Debuggen und zu beheben).
Die Lernkurve ist zu steil für Durchschnittliche Entwickler. Es sei denn, Sie haben ein maven-Rakete-Wissenschaftler (und Evangelisten) auf Ihr Projekt, vergiss es. Ihre Durchschnittliche Entwickler nicht investieren die Zeit, um zu lernen maven selbst. Jemanden im team zu sein, muss der Experte so kann der rest eigentlich software entwickeln.
InformationsquelleAutor der Antwort
Habe ich nur eins zu sagen : zu viele beschwert... Vielleicht auch nicht das perfekte tool, aber es gibt definitiv zu viele beschwert...in der Tat, es fügt einige Komplexität, und Sie schlagen könnte einige Straßensperren(wir haben nicht gefunden, was unlösbar), aber am Ende werden Sie die Vorteile sehen.
Las ich vor ein paar Wochen über einige Kerl, verbrachte, (das ist, was er behauptet) mehr als 500 Stunden zu verwenden, Maven...könnten Sie schreiben, ein paar Maven-plugins & erstellen Sie Ihre Anwendung in 500 Stunden.
Und durch die Art und Weise, es ist open source und wenn Sie ein problem melden oder zu beheben
PS. Ich bin nicht Teil von Maven-team, einfach nur ein normaler user, nichts mehr.
InformationsquelleAutor der Antwort
Ich bin damit einverstanden, ich verstehe nicht, warum sich jeder, hat, verwendet Maven würde sich für alle anderen Werkzeuge.
Ich denke, der Unterschied läuft darauf hinaus, Imperativ vs. deklarativ. Die Programmierer beginnen zu lernen imperative Programmierung, das ist Ameise, es ist ein Komfort-zone zu bleiben, in einer imperativen Sprache, auch wenn es länger dauert, Skript-Dateien, die Sie fühlen, wie können Sie ihn jederzeit ändern. Maven ist deklarative, haben Sie Vertrauen die Dinge sind korrekt deklariert, und wenn Sie nicht so funktionieren, wie Sie erwarten, was tun Sie? Dies gepaart mit schlecht dokumentiert plugins hilft nicht. Das ist, warum diese andere tools, die maven-Funktionen, aber mit einem imperativen Stil sind beliebt.
Ich würde das gleiche argument Wicket/Wandteppich über JSP, warum in der Welt würde jemand verwenden JSP-Skript-Stil ist, wenn Sie erklären können Komponenten zu verwenden? Es geht zurück in die comfort zone. Ich denke, deklarative wird immer beliebter und Maven ist eine dieser Technologien, die schiebt den Umschlag, aber da wir Massiv skalierbare Computer, deklarative Sprachen und Techniken werden mehr Komfort-zone, und standard-tarif.
InformationsquelleAutor der Antwort
Maven ist eine großartige Werkzeuge, die Konzepte und worlflow es stellt her ein großer Sprung nach vorn, von den Tagen nicht so weit, wenn wir nur gebückt tape-code zusammen, um software zu erstellen (ich bin nur jetzt Tauchen in eine legacy-Deplhi-app mit über 1M LOC.. ho der Schmerz... wie sehr ich vermisse Maven)
Diesem wird gesagt.. IMHO maven noch in den Kinderschuhen, Dokumentation, obwohl viel besser als vorher, ist immer noch knapp und schwer zu bekommen. Plugin-Steuerung hat noch ein paar Knicke in, kann es schwierig werden, die vollständige Kontrolle über Ihre build-Umgebung. Auch das Verhalten des Systems noch viel ändert von einer version zur nächsten, so ist es schwer zu garantieren, stabil baut in der Zeit.
So, ich kann sehen, warum Menschen würde backoff von Maven kommen von der Ameise zum Beispiel. Maven, Ant-Benutzer, hat viele Magische Eigenschaften und Verhalten, schafft eine unangenehme aura der Unsicherheit, das sitzt nicht sehr gut mit den typischen build-master-paranoia, die wir bekommen, wenn wir beginnen, die Bereitstellung von apps für client und stabil möchten versionning.
Trotz all dieser, sind Sie auf dem richtigen Weg und das langsame eindringen, es sieht eigentlich eine "gute Sache", weil es im halten der Wachstum des Systems innerhalb eines überschaubaren tobt, so dass die Probleme überwunden sind in der Zeit.
Lernen Ant als build-system vielleicht die bessere erste Schritt wird es helfen Sie verstehen die Anforderungen und Schwierigkeiten in einem zu bauen. Auch wenn Maven ist nicht handeln, wie Sie wollen, Sie können immer rückgängig zu Ant und integrieren Sie in das maven größeres Bild.
Ziele Maven versucht zu erreichen sind lobenswert und die Straße ist sehr Komplex. Aber wenn Sie lassen Sie Ihren Geist zu extrapolieren, was wäre die Welt wie im Zeitalter der Informationen, die Sie schnell realisieren, dass beim manuellen Umgang mit Abhängigkeiten zu dem Namen nur ein Aspekt von Maven werden bald nur mir schlicht unmöglich.
Wenn Maven scheitert Mangels Annahme lässt aber nur die Idee von Konvention über Konfiguration erreicht haben, eine großartige Sache schon...
... Aber es ist so viel mehr, dass.
Lange Geschichte kurz :
Meine 2 cent
InformationsquelleAutor der Antwort
Habe ich kurz gearbeitet, bei einem Unternehmen um 2005 hatte ein Ant-build-mit rund 80 Teilprojekte. Sie erkannten, wie wichtig es für ein team zu verwalten, die Tests und Freigaben, also musste ein reproduzierbarer build, aber die Modul-Abhängigkeiten Komplex und schwer für alle zu visualisieren, ohne grafische Werkzeuge.
Was Sie Tat, war der Roman eher für die Zeit. Die Anerkennung, dass Sie überprüfen könnten, werden in der Eclipse-Metadaten und die Metadaten (XML) war leicht zu analysieren, Sie schrieb ein Ant-plugin zu Lesen .classpath-Dateien und erstellen der Abhängigkeiten für den formalen Aufbau, die Art und Weise.
Lustig, niemand in der Firma wusste, wie das wirklich funktionierte, Sie wusste nur, dass, wenn jemand Durcheinander Ihre Eclipse bauen und überprüft, alles brechen würde. Die Jungs im release-management wusste, wie die Artefakte erzeugt und verpackt, die Entwickler haben verstanden, dass das bauen war eine große schwarze box, die angepasst werden kann in Eclipse, aber keine der Gruppen verstanden, die andere domain.
Das komische ist Sie hatte MacGyvered Maven zusammen und hat nicht einmal bemerkt.
Diese Geschichte ist wichtig für ein paar Gründe. Erste, für Geschäfte, die nicht wissen, Maven und sind nicht immer gehen, um groß zu werden, Maven wäre des guten zuviel. Ich würde sagen, builds, die über ein paar Dutzend Module, die schwierig, ohne Maven. Zweitens, während Maven könnte scheinen, wie es ist "schlecht dokumentiert", und "führt über die bauen", die Tatsache ist, es ist mehr Dokumentation als vorhanden ist für 98% der lokal integrierten benutzerdefinierten prozeduralen baut die es gibt. Mit einem Maven-build, wer weiß, Maven können gemietet werden, um daran zu arbeiten, das ist gut oder schlecht, je nach Perspektive des synthetischen job-Sicherheit durch interne Priesterschaften. Schließlich, während viele Sterne-Entwickler, die Eclipse verwenden, die diejenigen, die nicht an den start zu gehen, nur weil Sie einen job für Sie. Sie werden oft einfach woanders hingehen.
Maven erfordert auf jeden Fall eine Investition zu lernen, aber wie es sich herausstellt, ist es nicht mehr Investitionen, als wenn alle anderen Sachen (wie repositories und Dokumentation) berücksichtigt werden, die auf eine massive errichten. Was am meisten zählt an diesem Tag und Alter, ist die Interoperabilität mit Maven Central Repository, und dass schließlich erfordert POMs. Es ist möglich, zu synthetisieren POMs mit tools wie SBT und Gradle, aber wenn jemand in der Gruppe muss wissen, wie zu Debuggen, um die Dinge veröffentlicht, die Punkt, der nicht lernen Maven ist sowas von irrelevant.
Eines Tages Maven Central wird nicht so wichtig sein, aber bis dahin...
Jedenfalls, es gibt eine Menge Gründe für und gegen Maven. Es ist der de-facto-build gibt, da sonst die anderen build-tools gibt, würde nicht verlassen sich auf Maven Central, wie Sie es tun.
InformationsquelleAutor der Antwort
Mit einem Maven basierten Projekt-Struktur, können Sie ganz einfach durchzusetzen SoC (Separation of Concerns). Wenn Sie es falsch machen und bekommen zirkuläre Abhängigkeiten, maven wird nicht bauen.
Maven, verwendet Veröffentlichungen, die Trennung von Bedenken und Dependency-Management ist eine Disziplin.
Wenn Sie auf "hack" Ihren Weg um ihn herum, Sie konnte. Aber dann wieder, ich würde empfehlen die Verwendung von Maven als Disziplin. Sie fahren mit einem team Disziplin. Dein Leben wird mehrere Falten härter, wenn Sie beschließen, mehrere Disziplinen (sagen Sie, Sie bauen ein Projekt in Maven und eine in Gradle).
Umstellung auf die neuen Disziplinen beinhaltet eine unternehmensweite Anerkennung der Gründe für ihn zu existieren. Es sei denn, Sie sind ein kleines team, stick mit einer Disziplin, die wurde mal getestet. Maven wurde.
Als für die Netbeans-Entwickler, tun Sie es nicht, weil andere es tun. Es ist wie an Gott zu glauben, weil andere es tun.
Wenn alle an Bord sind, versuchen Gradle.
InformationsquelleAutor der Antwort
Nun, für eine Sache, die Umfrage ist kaum genauer Betrachtung sahen Sie es auf der NetBeans-Seite. Wenn es war, die von NetBeans (im Gegensatz zu einem link
fromNetBeans), dann noch wahrscheinlich, dass die große Zahl der Entwicklernotläuft NetBeans haben es verpasst. Maven-Nutzung ist geringer im Vergleich zu Ant, aber nur, um wie viel tiefer ist nicht wirklich bekannt.Andere, Apache Ant kam zuerst. Es ist immer noch sehr relevant heute, denn es bietet leistungsfähige Funktionen und Flexibilität. Maven ermutigt zu einer herkömmlichen oder standardisierten Ansatz zur Projektstruktur und zu bauen. Die meisten der bestehenden Projekte entspricht nicht der Maven-Konvention und daher viele Projekte sind einfach nicht die Mühe gemacht, verbringen Sie den Aufwand für die Umstellung Ihrer bereits gut entwickelten Ant-build-system in ein anderes, vor allem, wenn Maven nicht etwas anbieten, dass Ihre Ant-build schon kann.
InformationsquelleAutor der Antwort
Bezüglich der alternativen, der einzige, den ich kenne neben homegrown-system mit Ant ist Apache Ivy
InformationsquelleAutor der Antwort
Mein Problem mit Maven ist, dass eine der wichtigsten Dinge, die es tut, ist nicht best practice. Maven wird gehen und laden Sie die neueste version einer Abhängigkeit, die Sie haben. Während das klingt gut, es ist eine schlechte Praxis. Ich will die Abhängigkeiten für mein Projekt in meinem Projekt, weil ich nicht wollen, dass jeder Entwickler zu haben, der Unterschied Versionen von jar-Dateien und ich definitiv nicht wollen, ungetestet Abhängigkeiten verwendet werden, wenn die Bereitstellung von prod.
Wenn maven hatte eine einfache Möglichkeit, mir zu erlauben, Paket die Abhängigkeiten mit dem Projekt und laden Sie Sie für mich, ich würde es nutzen. Für jetzt, ich haben es nur installiert, weil einige code ich zu tun habe, zwingt mich, es zu benutzen.
Ja, ich weiß, es ist möglich, eine Abhängigkeit repository in mein Projekt und mein Projekt verwenden, aber das ist ein riesiger Schmerz. Ich möchte nur einen lib-Ordner in meinem Projekt und sagen, maven, das sind die Gläser, die ich verwende. Zeitraum. Ich würde viel lieber schreiben Sie eine ant build.xml Datei als verbringen Tonnen von mal zu schreiben pom.xml -Dateien.
InformationsquelleAutor der Antwort
Ich denke maven ist wie der Objekt-orientierten Programmierung, dass es ist schwer zu meistern-nach Jahren der strukturierten Programmierung, aber es hat starke Vorteile gegenüber imperativen tools wie Ant. Ich Liebe maven, obwohl ich muss zugeben, es hat mich etwa 3 Tage, um es zu lernen, um eine sub-level gemütlich und setzten Sie mit bestehenden eclipse-wtp-Projekte mit abhängigen Projekte und viele externe jars, und mit eclipse und m2e. Einmal gelernt und umgesetzt, es ist viel einfacher und viel mehr Reiniger und organisiert.
Denke ich, dass Maven wurde Massiv verabschiedet, und ich bin nicht einverstanden mit der Aussage, dass "so wenige Menschen nutzen Maven". Wenn man googelt für MVN-Respository heruntergeladen, oder besuchen Sie die SpringSource.org Website findet man, wie viele nützliche Bibliotheken und Projekte sind gebaut mit Maven.
InformationsquelleAutor der Antwort
Maven hat eine ziemlich steif Lernkurve. Seine kopfüber von den meisten build-control-Systeme. Die Mehrheit pif-das sind die Nachfahren von Machen und, zu einem Grad oder einem anderen, ändern empfindlich Skript-engines. Sie sagen, was die build-Vorgänge werden in einer scripted Mode.
Maven, auf der anderen Seite funktioniert ein standard-Modell erstellen, dass Sie mit Ihrem code.
Seine ganz mächtig, aber NICHT einfach zu bedienen. Seine beste Eigenschaft ist mit remote-repositories, und diese kommt wieder zurück in die andere Arten von build-tools.
InformationsquelleAutor der Antwort
Maven macht Projekt-Managern und anderen (nicht-Entwickler) menschliche Eingriffe obsolet. Also, warum nicht? Ok, es gibt einige Probleme und einige Mängel, aber für jetzt nur ivy bekommt nah genug. Kommende releases, sollte eine Funktionelle Analyse, die generation Mojo oder sogar erweiterte integration von kontinuierlichen build-Plattformen und system-set-up Mojo.
Persönlich, ich' m wirklich begeistert von der grails-Umgang mit Projekt-Abhängigkeiten und plugins seit einer Weile jetzt. Liebe es einfach.
InformationsquelleAutor der Antwort
Ich glaube Maven kann nahezu alles, was Ant machen kann, noch, wenn Ihr code gekoppelt ist, viel mit der Ameise dann kann man immer noch aufrufen von Ant in Maven.
Ich nur das problem das ich sehe ist, dass die Dokumentation nicht so gut, aber mit der Zeit verbessern wird.
Hoffe, das hilft. Kurz über Maven, Vergleich zwischen Ant & Maven
InformationsquelleAutor der Antwort
EBuild ist eine moderne alternative zu Maven.
Verwenden wir es für unsere Entwicklung. Es ist wirklich gut. Ich muss jedoch einschränkend festgestellt werden, dass durch die Feststellung, dass mein Bruder es geschrieben hat.
Es einfach schafft /baut alle Ihre Projekte für Sie. Sie ein Projekt Auschecken, und ebuild übernimmt den rest. Es holt sich alle Abhängigkeiten und baut. Wenn Sie bereit zum release, der release script erzeugt dann die für Sie bauen.
Derzeit ist es darauf ausgerichtet, mit Eclipse und arbeitet nur mit SVN (mit der intention entwickelt, zur Unterstützung anderer SCM wie GIT usw).
InformationsquelleAutor der Antwort