Die folgenden Artefakte konnten nicht behoben werden: javax.jms: jms: jar: 1.1


77

Ich versuche, ein Maven-Projekt zu kompilieren, erhalte jedoch systematisch die folgende Fehlermeldung:

[ERROR]Failed to execute goal on project ...:
Could not resolve dependencies for project ...:war:1.0.0:
The following artifacts could not be resolved: javax.jms:jms:jar:1.1,
com.sun.jdmk:jmxtools:jar:1.2.1, com.sun.jmx:jmxri:jar:1.2.1:
Failure to find javax.jms:jms:jar:1.1 in http://mirrors.ibiblio.org/maven2/
  was cached in the local repository, resolution will not be reattempted until
  the update interval of maven2-repository.ibiblio.mirror has elapsed or
  updates are forced -> [Help 1]

Ich weiß über diesen Maven-Beitrag über Sun-Gläser Bescheid , aber er löst das Problem nicht.

Gibt es ein Repository, das ich in meinem angeben kann pom.xml?

Antworten:


83

Danke für die Vorschläge. Nachdem ich dies gelesen hatte, fand ich endlich eine Lösung für dieses Problem . Es stellt sich heraus, dass diese Abhängigkeiten von einer Abhängigkeit zu ZooKeeper herrühren.

Ich habe meine pom.xml wie folgt geändert und das Problem gelöst:

    <dependency>
        <groupId>org.apache.zookeeper</groupId>
        <artifactId>zookeeper</artifactId>
        <version>3.3.2</version>
        <exclusions>
            <exclusion>
                <groupId>com.sun.jmx</groupId>
                <artifactId>jmxri</artifactId>
            </exclusion>
            <exclusion>
                <groupId>com.sun.jdmk</groupId>
                <artifactId>jmxtools</artifactId>
            </exclusion>
            <exclusion>
                <groupId>javax.jms</groupId>
                <artifactId>jms</artifactId>
            </exclusion>
        </exclusions>
    </dependency>

2
Gute Problemumgehung. Ich hatte heute das gleiche Problem mit einer log4j-Abhängigkeit. Es sieht so aus, als ob maven-repository.dev.java.net/nonav/repository möglicherweise ein ungültiges Zertifikat hat (Chrome gibt mir eine große Warnung, wenn ich auf diese URL klicke). Das ist der Server, auf dem diese Deps gehostet werden, denke ich.
James Cooper

Ich erhalte auch eine SSL-Zertifizierungswarnung, habe jedoch festgestellt, dass die Domain nicht vorhanden ist. Es war wegen OpenDNS und ihrer Standard-Fallback-Seite.
Steve Buzonas

4
Es sieht so aus, als würde eine vorübergehende Abhängigkeit log4j:log4j:1.2.15diese seltsamen Abhängigkeiten einbeziehen. Das Ausschließen von log4j aus der Zookeeper-Abhängigkeit und das Einfügen einer neueren Version von log4j selbst scheint dieses Problem ebenfalls zu lösen.
JeroenHoek

1
@JamesCooper Überprüfen Sie dies ( unitstep.net/blog/2009/05/18/… ). Es erklärt das log4j-Problem.
smwikipedia

61

Wenn jemand noch jms1.1 verwenden möchte, fügen Sie das öffentliche jboss-Repository hinzu, und maven findet es ...

Projekt-> Abhängigkeiten:

  <dependencies>
    <dependency>
      <groupId>javax.jms</groupId>
      <artifactId>jms</artifactId>
      <version>1.1</version>
    </dependency>

Projekt-> Repositories:

  <repositories>
    <repository>
      <id>repository.jboss.org-public</id>
      <name>JBoss.org Maven repository</name>
      <url>https://repository.jboss.org/nexus/content/groups/public</url>
    </repository>  

Es klappt -

F:\mvn-repo-stuff>mvn verify
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building mvn-repo-stuff 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
Downloading: http://repo1.maven.org/maven2/javax/jms/jms/1.1/jms-1.1.pom
Downloaded: http://repo1.maven.org/maven2/javax/jms/jms/1.1/jms-1.1.pom (677 B at 0.8 KB/sec)
[WARNING] The artifact xml-apis:xml-apis:jar:2.0.2 has been relocated to xml-apis:xml-apis:jar:1.0.b2
Downloading: http://repo1.maven.org/maven2/javax/jms/jms/1.1/jms-1.1.jar
Downloading: https://repository.jboss.org/nexus/content/groups/public/javax/jms/jms/1.1/jms-1.1.jar
Downloaded: https://repository.jboss.org/nexus/content/groups/public/javax/jms/jms/1.1/jms-1.1.jar (26 KB at 8.5 KB/sec)


Fügen Sie dies in den Abschnitt <Repositorys> ein? In meinem Fall hat es nicht geholfen.
Haridsv

Ich habe das Repository in der Datei "Settings Settings settings.xml" abgelegt, aber es hat auch nicht für mich funktioniert.
Despot

Für mich gab es diesen Fehler. Konnte Artefakt org.jboss.com.sun.httpserver: httpserver: jar: 1.0.0.Final in java.net nicht finden ...... Wenn ich das Repository auf jboss ändere, wird es heruntergeladen jetzt .. danke
Dhrumil Shah

23

Log4 Version 1.2.17 behebt das Problem automatisch, da es von geronimo-jms abhängig ist. Ich habe das gleiche Problem mit der Version log4j-1.2.15.


Hinzugefügt mit mehr um das Problem


Die Verwendung von 1.2.17 löste das Problem während der Kompilierungszeit, aber der Server (Karaf) verwendete die Version 1.2.15, wodurch zur Laufzeit ein Konflikt entstand. Daher musste ich wieder auf 1.2.15 umsteigen.

Die JMS- und JMX-API waren zur Laufzeit für mich verfügbar, daher habe ich die J2ee-API nicht importiert.

Ich habe die Kompilierungszeitabhängigkeit von 1.2.17 verwendet, sie aber zur Laufzeit entfernt.

            <dependency>
            <groupId>log4j</groupId>
            <artifactId>log4j</artifactId>
            <version>1.2.17</version>
        </dependency>
....
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.felix</groupId>
                <artifactId>maven-bundle-plugin</artifactId>
                <extensions>true</extensions>
                <configuration>
                    <instructions>
                        <Bundle-SymbolicName>${project.groupId}.${project.artifactId}</Bundle-SymbolicName>
                                                          <Import-Package>!org.apache.log4j.*,*</Import-Package>

.....

14

Eine andere Lösung, wenn Sie Ihre Einstellungen nicht ändern möchten:

Laden Sie jms-1.1.jar aus dem JBoss-Repository herunter und folgen Sie dann:

mvn install:install-file -DgroupId=javax.jms -DartifactId=jms -Dversion=1.1 -Dpackaging=jar -Dfile=jms-1.1.jar


Es hat den ganzen Weg funktioniert, um das Projekt zu kompilieren. Vielen Dank. Eine Frage: Wenn ich den Ordner .m2 lösche, muss ich diesen Befehl erneut ausgeben. habe ich recht?
Hephestos

Wenn ich den Ordner .m2 lösche, muss ich diesen Befehl erneut ausgeben? << Ja, das tust du. mvn install kopiert ein Artefakt in Ihr lokales mvn-Repo.
Adrián Deccico

3

Versuchen Sie, Updates mit der cpuOption mvn zu erzwingen :

usage: mvn [options] [<goal(s)>] [<phase(s)>]

Options:
 -cpu,--check-plugin-updates            Force upToDate check for any
                                        relevant registered plugins

Es ist nicht so gut, -cpu zu benutzen. Hier ist der Grund, warum "die Befehlszeilenoption -cpu veraltet ist und in zukünftigen Maven-Versionen entfernt wird."
Despot

3

Tatsächlich besteht die eigentliche Lösung für dieses Problem darin, das in Maven Central verfügbare Artefakt jms-api-1.1-rev-1.jar zu verwenden: http://search.maven.org/#artifactdetails%7Cjavax.jms%7Cjms-api% 7C1.1-rev-1% 7Cjar


Ich denke, dies ist die beste Lösung für den Fall, dass Ihre Projekte von JMS abhängen. Auf diese Weise delegieren Sie auch die Auflösung von JMS an Maven, wie es im Idealfall zu erwarten wäre.
Danidemi

Einfache, einfache Lösung. Sie müssen kein neues Repository hinzufügen.
Downeyt

3

Ich hatte auch das gleiche Problem, als ich anfing, die folgende Maven-Abhängigkeitsversion für log4j (1.2.15) in meinem Projekt zu verwenden.

<dependency>
  <groupId>log4j</groupId>
  <artifactId>log4j</artifactId>
  <version>1.2.15</version>
</dependency>

Der folgende Fehler wurde auf mich geworfen.

The following artifacts could not be resolved: javax.jms:jms:jar:1.1, com.sun.jdmk:jmxtools:jar:1.2.1, com.sun.jmx:jmxri:jar:1.2.1: Could not transfer artifact javax.jms:jms:jar:1.1 from/to java.net (https://maven-repository.dev.java.net/nonav/repository): Cannot access https://maven-repository.dev.java.net/nonav/repository with type legacy using the available connector factories: BasicRepositoryConnectorFactory: Cannot access https://maven-repository.dev.java.net/nonav/repository with type legacy using the available layout factories: Maven2RepositoryLayoutFactory: Unsupported repository layout legacy -> [Help 1]

Ich habe angefangen, die folgende log4j (1.2.17) -Version zu verwenden, und es hat mir geholfen, dieses Problem ohne konfigurationsbezogene Korrekturen zu lösen.

 <dependency>
      <groupId>log4j</groupId>
      <artifactId>log4j</artifactId>
      <version>1.2.17</version>
    </dependency>

2

Eine Überprüfung von iblibliound java.netRepositories zeigen, dass jmx-bezogene JAR auch nicht vorhanden ist. Ich denke, Sie sollten jms manuell herunterladen und lokal installieren, wie hier beschrieben .


Genau. Dies löst die meisten Probleme. Durchsuchen Sie jarvana.com und suchen Sie nach dem Feldfeldtyp Projekt-ID: Artefakt-ID des JARs, nach dem Sie suchen. Wenn Sie die Datei nicht finden können, überprüfen Sie den POM und versuchen Sie herauszufinden, von wo Sie sie herunterladen können (siehe downloadUrl hier: jarvana.com/jarvana/inspect-pom/com/sun/jdmk/jmxtools/1.2.1 /… ). Verwenden Sie nach dem Herunterladen den folgenden Befehl: mvn install: Installationsdatei -DgroupId = groupIdOfJar -DartifactId = ArtefaktIdOfJar -Dversion = versionOfJar -Dpackaging = jar -Dfile = "pathToJar.jar" -DgeneratePom = true
despot

Schauen Sie sich auch die verschiedenen Repositories hier an: docs.codehaus.org/display/MAVENUSER/Mirrors+Repositories And Mavens Leitfaden zu Spiegeln und Repositories: maven.apache.org/guides/mini/guide-mirror-settings.html
despot

0

Sie importieren eine Abhängigkeit, und diese Abhängigkeit ist abhängig von com.sun.jmx:jmxri:jar:1.2.1und anderen, com.sun.jmx:jmxri:jar:1.2.1kann jedoch nicht im zentralen Repository gefunden werden.

Versuchen Sie also besser, eine andere Version zu importieren.

Angenommen, Ihre Abhängigkeit lautet log4j, und Sie können versuchen, sie zu importieren log4j:log4j:jar:1.2.13.


0

Möglicherweise nicht genau das gleiche Problem. aber es gibt einen schönen Artikel in der gleichen Zeile hier


Fasst den Artikel am besten zusammen, falls der Link kaputt geht
cosbor11
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.