(Maven) m2eclipse stellt keinen Maven Library Container zur Verfügung

[xhi2018]

Hallo,

ich versuche gerade bestehende Java Projekte die mit Eclipse entwickelt werden zukünftig mit maven bauen zu lassen - ein ziemlich "schweißtreibende" und zeitaufwendige Sache. Allzu viel Erfahrung habe ich diesbezüglich noch nicht und mache auch jeden Tag neue, unerwartete Erfahrungen mit maven & Co. Aktuell kann ich mir folgende Situation nicht erklären...

In Eclipse 3.6 (Helios) hab ich das maven Plugin m2eclipse (Version 0.12.1.20110112-1712) installiert.

In dem pom.xml des Projekts habe ich eine dependency zu junit eingetragen

1
2
3
4
5
6
7
8
9
10
...
<dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.8.2</version>
      <scope>compile</scope>
    </dependency>
  </dependencies>
...

Das Handbuch "m2eclipse - Maven Integration For Eclipse" von Sonatype verstehe ich so, dass dem Eclipse Projekt dann ein Library Container (lt. Handbuch: "Maven Dependency Container") hinzugefügt wird - ähnlich dem JRE System Library Container - über den dann die Abhängigkeit zu der junit library zur Verfügung gestellt wird.

Doch bei mir wird dem Eclipse Projekt dieser Library Container leider nicht hinzugefügt, auch nicht nachdem ich in der .classpath des Projektes diesen manuell hinzugefügt habe:

1
2
3
4
5
...
    <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
    <classpathentry kind="con" path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/>
    <classpathentry kind="output" path="bin"/>
...

Wegen der fehlenden library kann ich das Projekt über m2eclipse in Eclipse auch nicht bauen/installieren.
Wenn ich maven auf der Konsole - außerhalb von Eclipse - aufrufe, dann geht compile - install - usw.... fehlerfrei.

In Eclipse ist die classpath variable M2_REPO - Window > Preferences > Java > Build Path > Classpath Variables - korrekt auf das Verzeichniss des lokalen maven Repositories auf meinem Rechner gesetzt...

Hat jemand eine Ahnung was bei mir falsch sein könnte...?

[maki]

Der Scope von JUnit sollte nicht compile, sondern test lauten.
M2_REPO solltest du entfernen, ist nicht für m2eclipse gedacht.

Versuche doch mal das hier:
Rechtsklick aufs Projekt -> Maven -> Update Project Configuration
Dadurch werden Dateien wie .classpath und .project generiert/geändert.

Builds nach Maven konvertieren ist keine Aufgabe für Maven Anfänger, ist schon für Erfahrene und Experten schwierig genug.

[kama]

Hi,

der erste Schritt ein Projekt nach Maven zu konvertieren ist. Den Build auf der Command line am laufen zu haben...danach reicht ein Import nach Eclipse und alles muss laufen...

Maki hat auch schon bemerkt, dass das kein Job für Anfänger in Maven ist...

Gruß
Karl Heinz Marbaise

[xhi2018]

Hallo & vielen Dank für Deine Antwort,

Zitat: maki

	Der Scope von JUnit sollte nicht compile, sondern test lauten. M2_REPO solltest du entfernen, ist nicht für m2eclipse gedacht.

Das mit JUnit ist war jetzt nur als Beispiel gedacht. Ich hab auch noch andere dependencies in den pom.xml eingetragen. Für mich ist der springende Punkt bei der Sache der, dass der Maven Library Container dem Eclipse Projekt gar nicht hinzugefügt wird bzw. was ich machen muß, damit dieser Library Container automatisch hinzugefügt wird...?
Die Variable M2_REPO kann ich in Eclipse gar nicht entfernen. Diese ist in den Properties von Eclipse als "non modifiable" gekennzeichnet...

Zitat: maki

	Versuche doch mal das hier: Rechtsklick aufs Projekt -> Maven -> Update Project Configuration Dadurch werden Dateien wie .classpath und .project generiert/geändert.

Hab ich schon mehrfach versucht - hat aber leider nicht zu dem gewünschten Erfolg geführt...

[maki]

Projekt schliessen und dann wieder öffnen, ansonsten neu importieren.
Irgendwoher muss dioe M2_REPO Variabkle ja herkommen, hoffe du rufst keine eclipse:eclipse cvon der Kommandozeile auf...

[xhi2018]

Hallo & danke für Deine Antwort!

Zitat: kama

	der erste Schritt ein Projekt nach Maven zu konvertieren ist. Den Build auf der Command line am laufen zu haben...

wie gesagt, auf der Command line und in der CI-Umgebung (Hudson) läuft mvn compile und mvn install usw. fehlerfrei..!
Leider halt noch nicht im Eclipse...

Zitat: kama

	danach reicht ein Import nach Eclipse und alles muss laufen... Maki hat auch schon bemerkt, dass das kein Job für Anfänger in Maven ist...

na dann bin ich ja schon ein "intermediate"

Dann ist euch das von mir beschriebene Verhalten also nicht bekannt...?! Ich werd' mal den Tipp mit dem Import des Projekts in Eclipse versuchen - Danke!

[kama]

Hi,

Zitat: xhi2018

	Dann ist euch das von mir beschriebene Verhalten also nicht bekannt...?! Ich werd' mal den Tipp mit dem Import des Projekts in Eclipse versuchen - Danke!

Vorher die .settings, .classpath und .project aus dem projekt löschen (von Command line aus)
und dann Project Explorer -> Import -> Existing Maven Project -> Auswahl des Verzeichnisses und dann Ok...
Wenn du noch Code-Generatoren drin hast, danach einmal auf das Project im Project Explorer -> Maven -> Update Project configuration...

Hast Du eventuell noch ein maven-eclipse-plugin in der POM drin ?

Gruß
Karl Heinz Marbaise

[xhi2018]

Hallo,

Zitat: maki

	Projekt schliessen und dann wieder öffnen, ansonsten neu importieren.

Projekt schließen & öffnen hilft leider auch nicht. Zum neu importieren siehe auch meine Antwort weiter unten...

Zitat: maki

	Irgendwoher muss dioe M2_REPO Variabkle ja herkommen, hoffe du rufst keine eclipse:eclipse cvon der Kommandozeile auf...

Ich hätte jetzt behauptet, die M2_REPO Variable kommt durch das m2eclipse Plugin...? Nein - eclipse:eclipse rufe ich nicht von der Kommandozeile auf.

Danke für Deine Tipps!

[xhi2018]

Hallo,
vielen Dank für Eure Hilfe & Tipps,

Zitat: kama

	Vorher die .settings, .classpath und .project aus dem projekt löschen (von Command line aus) und dann Project Explorer -> Import -> Existing Maven Project -> Auswahl des Verzeichnisses und dann Ok... Wenn du noch Code-Generatoren drin hast, danach einmal auf das Project im Project Explorer -> Maven -> Update Project configuration... Hast Du eventuell noch ein maven-eclipse-plugin in der POM drin ?

hab ich jetzt mal gemacht - doch leider führt dies auch nicht zu dem gewünschten Ergebnis. Ist es vielleicht noch wichtig, dass es sich bei den Projekten alle um sogenannte Multi Modul Projekte handelt..? Was ich gemacht habe:

• Ich hab mir die Projekte vom SVN in ein temp. Workspace ausgecheckt

• Danach im "richtigen" Workspace die Projekte wie oben beschrieben importiert

Ergebnis:
Die importierten Projekte befanden sich danach nicht im "richtigen" Workspace Verzeichnis, sondern waren im "richtigen" Eclipse Workspace nur "verlinkt" - also physisch waren die Projekte noch im temp. Workspace. Ich hab' auch nichts gefunden, wie es möglich sein könnte die Projekte beim Import in das "richtige" Workspace Verzeichnis zu kopieren - also so dass ich den temp. Workspace löschen könnte.

Dann waren die Multi Modul Projekte auch flach nebeneinander im Workspace importiert. Ich benötige diese aber untereinander - also parent pom.xml und in Verzeichnissen darunter dann die jeweiligen Module pom.xml . Die gelöschten .classpath - .project und .settings wurden leider auch nicht wieder erzeugt...

hmmm - mach ich hier etwas total falsches..

[maki]

Zitat:

	* Ich hab mir die Projekte vom SVN in ein temp. Workspace ausgecheckt * Danach im "richtigen" Workspace die Projekte wie oben beschrieben importiert

Ganz schön umständlich...

Wie es richtig geht:
Mit Eclipse (Subversive) das Parent Projekt in den Workspace auschecken.
Dann als Maven Projekte importieren (nur ein einziges mal), den Dateibrowser dabei in das Verzeichnis des Parentsprojektes navigieren, du solltest eine Liste mit allen Modulen angezeigt bekommen.

[kama]

Hi,

Zitat: xhi2018

	Hallo,Ist es vielleicht noch wichtig, dass es sich bei den Projekten alle um sogenannte Multi Modul Projekte handelt..? Was ich gemacht habe: Ich hab mir die Projekte vom SVN in ein temp. Workspace ausgecheckt Danach im "richtigen" Workspace die Projekte wie oben beschrieben importiert Ergebnis: Die importierten Projekte befanden sich danach nicht im "richtigen" Workspace Verzeichnis, sondern waren im "richtigen" Eclipse Workspace nur "verlinkt" - also physisch waren die Projekte noch im temp. Workspace. Ich hab' auch nichts gefunden, wie es möglich sein könnte die Projekte beim Import in das "richtige" Workspace Verzeichnis zu kopieren - also so dass ich den temp. Workspace löschen könnte.

Auschecken im richtigen Ecliipse workspace und nicht irgendwo anders....
Dann dass oberste Project also das Verzeichnis mit der root-Pom deines Multimodule Projekte importieren...und nur das Eine...
Dann werden alle Projekte in den Workspace von Eclipse importiert....
Die Struktur wird platt geklopft, da Eclipse keinen Baum kann....also alles nebeneinander...Funktionieren tut es aber trotzdem...

Gruß
Karl Heinz Marbaise

[xhi2018]

Hallo,

Zitat: kama

	Auschecken im richtigen Ecliipse workspace und nicht irgendwo anders.... Dann dass oberste Project also das Verzeichnis mit der root-Pom deines Multimodule Projekte importieren...und nur das Eine... Dann werden alle Projekte in den Workspace von Eclipse importiert.... Die Struktur wird platt geklopft, da Eclipse keinen Baum kann....also alles nebeneinander...Funktionieren tut es aber trotzdem...

Also so langsam kommen wir der Sache hoffentlich näher - funktionieren tut's zwar immer noch nicht, aber ich vermute stark, dass ich irgendwo in den maven Konfigurationen pom.xml einen Fehler habe.
Denn wenn ich es genau so mache wie Du beschreibst, wird diese Exception im Eclipse ErrorLog geworfen:

Zitat:

	java.lang.IllegalArgumentException: Path must include project and resource name: / at org.eclipse.core.runtime.Assert.isLegal(Assert.java:63) at org.eclipse.core.internal.resources.Workspace.newResource(Workspace.java:1795) at org.eclipse.core.internal.resources.Container.getFolder(Container.java:221) at org.maven.ide.eclipse.internal.project.registry.EclipseWorkspaceArtifactRepository.resolveAsEclipseProject(EclipseWorkspaceArtifactRepository.java:73) at org.maven.ide.eclipse.internal.project.registry.EclipseWorkspaceArtifactRepository.findArtifact(EclipseWorkspaceArtifactRepository.java:86) at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:286) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.resolveArtifacts(DefaultRepositorySystem.java:304)

tja - nur welcher "Path must include project and resource name" ..?

Hat ja jemand von Euch eine Idee - ich wäre super dankbar dafür...!

[kama]

Hi,

hilfreich wäre jetzt die POM.xml ...

Gruß
Karl Heinz

[mvitz]

Ich habe übrigens bisher auch noch nie Probleme damit gehabt, wenn der Ort des SVN Checkouts und der Eclipse Workspace unterschiedlich waren. Aber eleganter ists sicherlich, wenn das derselbe Ort ist und man ein Eclipse SVN Plugin (ich präferiere Subversive) nutzt.

[xhi2018]

Zitat: kama

	hilfreich wäre jetzt die POM.xml ...

sicherlich...

Ich hab gestern und heute noch so einiges ge- & versucht - leider ohne Erfolg. Bei meinen Eclipse Projekten handelt es sich allesamt um MultiModul Projekte - die Struktur der Projekte sieht also so aus:

+-parent pom.xml
¦
+--facility
¦  +--src
¦  ¦  +--api
¦  ¦  ¦  + modul pom.xml 
¦  ¦  ¦  +--org
¦  ¦  ¦       +--myname
¦  ¦  ¦           +--foobar
¦  ¦  ¦               +--facility
¦  ¦  ¦                  + ...
¦  ¦  +--impl
¦  ¦     + modul pom.xml 
¦  ¦     +--org
¦  ¦         +--myname
¦  ¦            +--foobar
¦  ¦               +--facility
¦  ¦                  + ...
¦  +--test
¦     + modul pom.xml 
¦     +--org
¦        +--myname
¦           +--foobar
¦              +--facility
¦                 + ...
+--service
¦  +--src
¦  ¦  +--api
¦  ¦     + modul pom.xml 
¦  ¦     +--org
¦  ¦     ¦  +--myname
¦  ¦     ¦     +--foobar
¦  ¦     ¦        +--service
¦  ¦     ¦           + ...
¦  ¦     +--lib
¦  ¦        +--ini
¦  ¦           +--system
¦  ¦              +--resources
¦  ¦                 + ...
¦  +--test
¦     + modul pom.xml 
¦     +--org
¦        +--myname
¦           +--foobar
¦              +--service
¦                 + ...
...

In der Exception kann ich leider nicht erkennen in welcher der vielen pom.xml das Problem/Fehler liegen könnte. Anhand dem was ich so gefunden habe, könnte es an diesem Abschnitt in den pom.xml liegen. Hier habe ich Anpassungen für meine Projekte vorgenommen:

1
2
3
4
5
6
7
8
...
    <build>
        <sourceDirectory>./</sourceDirectory>
        <outputDirectory>../bin</outputDirectory>
        <directory>../target/${project.parent.artifactId}/${project.artifactId}</directory>
        <finalName>${project.parent.artifactId}-${project.artifactId}__V${project.version}</finalName>
    </build>
...

[mvitz]

Also source, output und directory würde ich NICHT ändern, außer du hast einen sehr guten Grund dafür... Finalname kann man zwar ändern, würde ich aber auch nicht tun, was gewinnst du dadurch? Wenn ihr alle Projekte umstellt, solltet ihr euch am besten auch an die Standards halten, das vereinfacht nun mal massiv viele Dinge!

[xhi2018]

Zitat: mvitz

	Also source, output und directory würde ich NICHT ändern, außer du hast einen sehr guten Grund dafür... Finalname kann man zwar ändern, würde ich aber auch nicht tun, was gewinnst du dadurch? Wenn ihr alle Projekte umstellt, solltet ihr euch am besten auch an die Standards halten, das vereinfacht nun mal massiv viele Dinge!

ja - da hast Du absolut recht... Aber hierbei handelt es sich um Vorgaben/Strukturen die nun mal so sind wie sie sind. Diese zu ändern bedeutet - eher geht ein Kamel durchs Nadelöhr...

Die Buildergebnisse <finalName> (jar-Files) müssen leider so heißen, da diese vom Installationsprozess und auch zur Laufzeit des Programms - auf was ich keinen Einfluss habe - so vorausgesetzt werden. Auch muss ich <sourceDirectory> ändern, da maven-Standard den Sourcecode dann ja unter einem Verzeichnis ...src\main\java erwarten würde, was bei mir nicht der Fall ist...

[kama]

Hi,

also das Thema Änderungen der Konventionen in Maven ist eine Sache die man nur dann machen sollte, wenn man 100%ig weiß warum und weshalb man es macht und noch wichtiger: Ein sehr guter Grund muss vorhanden sein....

Die Struktur in einem Maven Projekt sieht immer gleich aus (siehe auch Maven - Introduction to the Standard Directory Layout)

  +-- pom.xml
  +-- src
         +--- main
                +--- java
                +--- resources
         +--- test
                +--- java
                +--- resources

Ergänzungen können noch sein, wenn es sich um WAR Projekte handelt etc. Aber von der obigen Struktur nur dann abweichen wenn es wirklich notwendig ist. Ich arbeite seit mehr 4 Jahren mit Maven und habe auch in großen Projekten noch keinen wirklichen Grund gefunden....(außer wir wollen das so)

Ich würde mir ernsthaft überlegen die Struktur:

+-parent pom.xml
¦
+--facility
¦  +--src
¦  ¦  +--api
¦  ¦  ¦  + modul pom.xml 
¦  ¦  ¦  +--org
¦  ¦  ¦       +--myname
¦  ¦  ¦           +--foobar
¦  ¦  ¦               +--facility
¦  ¦  ¦                  + ...
¦  ¦  +--impl
¦  ¦     + modul pom.xml 
¦  ¦     +--org
¦  ¦         +--myname
¦  ¦            +--foobar
¦  ¦               +--facility
¦  ¦                  + ...
¦  +--test
¦     + modul pom.xml 
¦     +--org
¦        +--myname
¦           +--foobar
¦              +--facility
¦                 + ...
+--service
¦  +--src
¦  ¦  +--api
¦  ¦     + modul pom.xml 
¦  ¦     +--org
¦  ¦     ¦  +--myname
¦  ¦     ¦     +--foobar
¦  ¦     ¦        +--service
¦  ¦     ¦           + ...
¦  ¦     +--lib
¦  ¦        +--ini
¦  ¦           +--system
¦  ¦              +--resources
¦  ¦                 + ...
¦  +--test
¦     + modul pom.xml 
¦     +--org
¦        +--myname
¦           +--foobar
¦              +--service
¦                 + ...
...

umzustellen...

+-parent pom.xml (modules: facility, ...)
¦
+--facility
     +-- pom.xml (modules: api, impl, test)
     +--api
           +--- pom.xml 
           +--src/main/java
                 +--myname
                       +--foobar
     +--impl
           + pom.xml 
           +--src/main/java
                 +--myname
                       +--foobar
     +--test
           + pom.xml 
           +--src/main/java
                 +--myname
                       +--foobar
...

Mit service und dem test genau die gleiche Struktur....

Ihr bzw. Du verletzt hier die Grundlegende Regel in Maven: "Convention over Configuration"....

Schaue Dir mal ein Beispiel von mir an wo auch mehrere Ebenen von Modulen existieren...das entspricht schon deiner Struktur....

Mich würde noch interessieren sind die Module "Test" auch tatsächlich Tests also Unit- oder Integrationstests?

MfG
Karl Heinz Marbaise

[kama]

Hi,

Zitat: xhi2018

	ja - da hast Du absolut recht... Aber hierbei handelt es sich um Vorgaben/Strukturen die nun mal so sind wie sie sind. Diese zu ändern bedeutet - eher geht ein Kamel durchs Nadelöhr... -

Und wer hat die Vorgaben gemacht? Es ist doch s***** egal wo der Source in einem Java Projekt liegt hauptsache ist doch, dass man mit Standard Tools arbeiten und entwickeln kann....solche Verballhornungen von Standards Kosten Aufwand/Zeit und somit Geld...Wer auch immer solche Vorgaben gemacht hat, hat keine Ahnung von den Konsequenzen...

Zitat: xhi2018

	jDie Buildergebnisse <finalName> (jar-Files) müssen leider so heißen, da diese vom Installationsprozess und auch zur Laufzeit des Programms - auf was ich keinen Einfluss habe - so vorausgesetzt werden.

Ok...dass kann man lassen, wenn es denn sein muß...

Zitat: xhi2018

	Auch muss ich <sourceDirectory> ändern, da maven-Standard den Sourcecode dann ja unter einem Verzeichnis ...src\main\java erwarten würde, was bei mir nicht der Fall ist...

Dann würde ich das schleunigst auf den Maven default ändern. Damit sparst Du dir eine Menge Arbeit...

Gruß
Karl Heinz Marbaise

[maki]

Kann kama nur zustimmen, man sollte schon eine echte Maven Struktur nutzen, und nicht versuchen Maven zu verbiegen, typischer Anfängerfehler... anstatt die Konventionen zu erlernen, verstehen und anzuwenden, meint man erstmal alles anders machen zu müssen und wundert sich dann über Fehler und enormen Aufwand.

Maven ist vieles aber nicht flexibel, wenn man meint unbedingt seine eigenen Konventionen durchsetzen zu müssen, ist man bei Maven falsch.
Egal wie unflexibel die Vorgaben sind, Maven ist noch viel unflexibler
Nimmt lieber Ant wenn du nicht bereit/in der Lage bist den "maven way" zu gehen.