Maven Plugin-Dependency

[JonnyRico]

Hi,

ich habe ein Maven-Plugin X, das ein Stück Software Y benutzt. Y kann durch "Plugins" (<-- das hat nichts mit Maven zu tun!) per Spring-Injection erweitert werden. An bestimmten Stellen werden Listen von Interfaces injiziert und wenn diese zur Laufzeit da sind, dann weden alle vorhanden abgearbeitet.

Was ich jetzt möchte ist, dass ich in meinem Projekt Z das Maven-Plugin X verwenden kann und den Classpath für die Pluginausführung um das Projekt A erweitere. Dieses enthält die Beans, die in Y injected werden sollen. Leider funktioniert dies nicht so 100% wie ich mir das vorstelle. Ich habe im Projekt Z folgende Config:

[XML]
<build>
<plugins>
<plugin>
<groupId>org.foo</groupId>
<artifactId>X</artifactId>
<version>0.1-SNAPSHOT</version>
<configuration>
...
</configuration>
<dependencies>
<dependency>
<groupId>org.foo</groupId>
<artifactId>A</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>
</plugin>
</plugins>

</build>
[/XML]

Leider werden die Klassen aus A durch X bzw. eigentlich Y nicht gefunden. Kann mir vielleicht jemand einen Tipp geben? Vielen Dank im Voraus.

Gruß

Jonny

 

[kama]

Hm...

Was ich jetzt möchte ist, dass ich in meinem Projekt Z das Maven-Plugin X verwenden kann und den Classpath für die Pluginausführung um das Projekt A erweitere.

Wird ja mit der angegebenen Konfiguration auch so gemacht...

Sprich X ist ein Plugin das während des Build Life-Cycles läuft...Der Classpath des Plugins X wird um den Artefact A ergänzt...

So was mir nicht klar ist wer ist bei dem ganzen Spiel nun Y ist und wo vor allem?

Gruß
Karl-Heinz Marbaise

 

[JonnyRico]

Hallo Karl-Heinz,

danke für deine schnelle Antwort. Ich hatte mir das eigentlich auch so gedacht (analog project-dependencies).
Y ist in diesem Beispiel nicht zu sehen. X implementiert AbstractMojo, passt die Parameter an und hat selbst eine Dependency zu Y, da Y die eigentliche Arbeit tut. Damit aber Y in diesem Beispiel die Arbeit korrekt verrichten kann, braucht es A im Classpath und das ist genau der Punkt, der nicht klappt ;(
Wenn ich mir im Projekt Z mit 'mvn dependency:resolve-plugins' angucke wie die Dependencies für die Plugins aussehen, ist auch zu erkennen, dass mein manueller Dependancy-Eintrag nicht zieht.

[INFO] ...
[INFO] Plugin Resolved: X-0.1-SNAPSHOT.jar
[INFO]     Plugin Dependency Resolved: Y-0.5-SNAPSHOT.jar
[INFO]     Plugin Dependency Resolved: maven-plugin-api-2.0.jar
[INFO] Plugin Resolved: ....

 

[kama]

Hi,

Y ist in diesem Beispiel nicht zu sehen. X implementiert AbstractMojo, passt die Parameter an und hat selbst eine Dependency zu Y, da Y die eigentliche Arbeit tut. Damit aber Y in diesem Beispiel die Arbeit korrekt verrichten kann, braucht es A im Classpath und das ist genau der Punkt, der nicht klappt ;(

Hast Du dir denn mal den Classpath angeschaut, da nämlich mit der Dependency genau das erreicht wird...

Wenn ich mir im Projekt Z mit 'mvn dependency:resolve-plugins' angucke wie die Dependencies für die Plugins aussehen, ist auch zu erkennen, dass mein manueller Dependancy-Eintrag nicht zieht.

[INFO] ...
[INFO] Plugin Resolved: X-0.1-SNAPSHOT.jar
[INFO]     Plugin Dependency Resolved: Y-0.5-SNAPSHOT.jar
[INFO]     Plugin Dependency Resolved: maven-plugin-api-2.0.jar
[INFO] Plugin Resolved: ....

Hm...Du solltest Dependencies nicht mit dem Classpath verwechseln...Hier wirst Du die Dependency auch nicht zu sehen bekommen...mach ein mvn -X clean package und schaue Dir dann den Classpath an...

Abgesehen davon wäre hier jetzt mal ein konkreter pom file wirklich hilfreich...

Abgesehen davon hört sich das Ganze ein wenig merkwürdigt an, dass über Spring Injection gearbeitet wird...Maven hat seinen eigenen DI (plexus bzw. Guice)..Warum hier Spring notwendig ist mir nicht klar...

Gruß
Karl-Heinz Marbaise