2010-12-08 2 views
0

Ich entwickle eine Web-App und nutze Maven für das Abhängigkeitsmanagement (duh). Einige der benötigten JAR-Dateien sind bereits im lib-Ordner des Servers verfügbar, stimmen jedoch nicht mit dem "maven naming scheme" überein, dh es fehlt das Versions-Suffix.Maven und AppServer Abhängigkeitsmanagement Best Practice

Ich möchte sie für die Entwicklung und Bereitstellung verwenden, aber ..
1. Ich kann Maven auf sie zeigen, weil Maven ein Versionsuffix zu benötigen scheinen. Ich kann es nicht im Pom weglassen.
2. Wenn ich die Abhängigkeit außerhalb Maven definiere, dann ist Maven offensichtlich nicht in der Lage zu bauen.
3. Umbenennen der Dateien in der Server-Distribution klingt wie ein Klud.

Was würde Brian Boitano tun? Ich meine, da ist sicher eine elegante Lösung, die mir keine der drei obigen Lösungen oder zumindest ein gutes Argument vor Augen führt.

Vielen Dank

PS. Ich benutze jboss 5.1 und maven 2.2.1 atm, aber sein Gegenstand zu ändern

+0

Ich denke, ich hätte die Frage "wie redundante Jar Deployment mit Maven zu vermeiden" benannt haben. also habe ich bisher 2 "best practices" - "versuche nicht schlau zu sein" von c0mrade und "nutze systemweite für lokale libs" von dimitrisli. Der Systemumfang sollte jedoch irgendwie veraltet sein. Ich frage mich, ob die Deprecation noch gültig ist in Bezug auf den relativen Pfad mit der Umgebungsvariablen wie JBOSS_HOME – kostja

Antwort

1

Sie können diese Gläser als eine Abhängigkeit mit einem system Geltungsbereich bereitstellen, wenn Sie explizit angeben möchten, wo sie leben. Für weitere Informationen werfen Sie einen Blick here

+0

danke, ich habe bereits herausgefunden, wie man mvn auf lokale jars zeigt, aber es gibt immer noch das suffix der versionssendung ... hast du auch eine idee dazu? – kostja

+0

Was meinst du mit Suffix-Problem? Wenn Sie in Ihrer Abhängigkeit System und fullPathFileWithoutVersionSuffix.jar bereitstellen, dann sollten Sie in Ordnung sein. – dimitrisli

+0

mein Schlechter, nicht Maven explizit auf das Glas, sondern auf die Lib-Ordner. funktioniert jetzt :) und mit $ {env.JBOSS_HOME} ist der Systemumfang nicht so schlecht – kostja

0

Wenn diese nicht proprietäre Bibliotheken sind, die Sie verwenden, würde ich empfehlen, dass Sie offizielle Versionen von denen von Maven Repository verwenden.

Wenn sie proprietär sind, können Sie jar manuell mit maven in Ihrem lokalen Repository installieren (Sie können Ihre Version, Suffixe, Gruppennamen, artifactid usw. verwenden) und sie dann in Ihrem Pom verwenden.

+0

danke. Es scheint so, als ob Ihre Lösung darin besteht, die Tatsache zu ignorieren, dass das Glas bereits da ist und einfach dem normalen Verfahren folgt. Das ist eine Option, die ich nicht erwähnt habe, aber: 1. Ich möchte redundante Implementierungen für gewöhnliche Jars vermeiden und 2. Warum bevorzugen Sie Repo-Jars gegenüber denen, die von der Server-Distribution bereitgestellt werden? – kostja

+0

@kostja 1. Weil das ist, wie Maven funktioniert, wenn Sie es nicht mögen, verwenden Sie es nicht. Sie müssen artifactId, groupId usw. haben. 2. Sie sind im Grunde genommen die gleichen, aber wenn Sie den Überblick über die neuesten Versionen behalten wollen, ist es einfacher, dass maven das für Sie tut, als dass Sie sich darum kümmern. – ant

+0

ich fürchte, die Wahl der Werkzeuge für ein Projekt ist nicht immer über persönliche Vorlieben, zumindest nicht meine persönlichen Vorlieben :) btw ich mag wirklich Maven, müssen Sie irgendwie nach der Verwendung von Ameisen. Ich bin gerade ziemlich neu dazu. Wie würden Sie ein Glas zwischen Webapps "the mvn way" teilen, ohne es zu duplizieren? – kostja