Plötzlich erhält man vom seinem Bamboo-Build mittels Maven2 folgende Meldung:
Unable to get dependency information: Unable to read local copy of metadata

Beim Blick in die Datei stellt sich heraus, dass es sich bei den maven-metadata-jaspersoft.xml um eine HTML-Datei handelt.
Diese beinhaltet den Hinweis, dass eine bestimmte URL nicht gefunden wird. Wir dachten, dass wir mit Nexus und unseren POMs auf der sicheren Seite wären, aber weit gefehlt. Dies kann übrigens auch passieren, wenn man zu Hause mit seinem neuen DSL spielt und der Provider einem statt 404 eine HTML-Seite durchreicht. So landen dann auch schon einmal HTML-Seiten als JAR-Dateien im Maven2-Repository.

Im Moment existiert noch keine befriedigende Lösung, soweit ich das gesehen habe.

Selbst wenn man sein Nexus-Repository-Proxy abgeschottet hat, muss man natürlich darauf achten, dass die POMs abgeschottet sind.

• alle repository-Einträge zeigen nur auf gekapselte Nexus-Repositories
• „central“ ist gesperrt


<repository>
<id>central</id>
<name>Maven Repository Switchboard</name>
<layout>default</layout>
<url>http://repo1.maven.org/maven2</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
<releases>
<enabled>false</enabled>
</releases>
</repository>


Das Gleiche gilt natürlich auch für die Plug-In-Repositories.

Aber dies nützt einem alles nichts bei dem Problem der transitiven-Repositories.


[INFO] artifact commons-collections:commons-collections: checking for updates from jaspersoft
[DEBUG] Checking for pre-existing User-Agent configuration.
[DEBUG] Adding User-Agent configuration.
[DEBUG] Connecting to repository: 'jaspersoft' with url: 'http://www.jasperforge.org/maven2'.


Besonders unangenehm ist uns das bei jaspersoft (http://www.jasperforge.org/maven2) aufgefallen.
(Siehe: jasperforge.org espforum, http://stackoverflow.com)

Currently, there's no way to exclude more than one transitive dependency at a time, but there is a feature request for this on the Maven JIRA site:

http://jira.codehaus.org/browse/MNG-2315

Da mogelt sich doch tatsächlich ein weiteres Repository in die Abarbeitungskette. Und das ist eine fatale Sicherheitslücke. Es bleibt einem nichts anderes übrig, als auf mögliche Transitivitäten zu achten mit dem Scannen seines JAR-Dependency-Baumes z. B. unter WEB-INF/lib.

Auf alle Fälle zeigt dieser Vorfall, dass eine solch komplexe und transitive Struktur, wie die Maven-Abhhängigkeiten, gepflegt und überwacht sein will. Wäre uns dieser Crash beim Deployment zum Kunden passiert …