Maven m2eclipse stellt keinen Maven Library Container zur Verfügung

X

xhi2018

Gast
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
Code:
pom.xml
des Projekts habe ich eine dependency zu junit eingetragen[XML]...
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.8.2</version>
<scope>compile</scope>
</dependency>
</dependencies>
...[/XML]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. :rtfm:

Doch bei mir wird dem Eclipse Projekt dieser Library Container leider nicht hinzugefügt, auch nicht nachdem ich in der
Code:
.classpath
des Projektes diesen manuell hinzugefügt habe:[XML]...
<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"/>
...[/XML]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
Code:
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...? ???:L
 
M

maki

Gast
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

Top Contributor
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
 
X

xhi2018

Gast
Hallo & vielen Dank für Deine Antwort,
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
Code:
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
Code:
M2_REPO
kann ich in Eclipse gar nicht entfernen. Diese ist in den Properties von Eclipse als "non modifiable" gekennzeichnet...:bahnhof:

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... :(
 
M

maki

Gast
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...
 
X

xhi2018

Gast
Hallo & danke für Deine Antwort!
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
Code:
mvn compile
und
Code:
mvn install
usw. fehlerfrei..! :)
Leider halt noch nicht im Eclipse... :(
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

Top Contributor
Hi,

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
 
X

xhi2018

Gast
Hallo,
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...
Irgendwoher muss dioe M2_REPO Variabkle ja herkommen, hoffe du rufst keine eclipse:eclipse cvon der Kommandozeile auf...
Ich hätte jetzt behauptet, die
Code:
M2_REPO
Variable kommt durch das m2eclipse Plugin...? Nein - eclipse:eclipse rufe ich nicht von der Kommandozeile auf.

Danke für Deine Tipps!
 
X

xhi2018

Gast
Hallo,
vielen Dank für Eure Hilfe & Tipps,
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
Code:
pom.xml
und in Verzeichnissen darunter dann die jeweiligen Module
Code:
pom.xml
. Die gelöschten
Code:
.classpath
-
Code:
.project
und
Code:
.settings
wurden leider auch nicht wieder erzeugt...

hmmm - mach ich hier etwas total falsches..???:L
 
M

maki

Gast
* 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

Top Contributor
Hi,

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
 
X

xhi2018

Gast
Hallo,
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
Code:
pom.xml
einen Fehler habe. :autsch:
Denn wenn ich es genau so mache wie Du beschreibst, wird diese Exception im Eclipse ErrorLog geworfen:
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...!:)
 

mvitz

Top Contributor
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.
 
X

xhi2018

Gast
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:
Code:
+-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
Code:
pom.xml
das Problem/Fehler liegen könnte. Anhand dem was ich so gefunden habe, könnte es an diesem Abschnitt in den
Code:
pom.xml
liegen. Hier habe ich Anpassungen für meine Projekte vorgenommen:[XML]...
<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>
...[/XML]
 
Zuletzt bearbeitet von einem Moderator:

mvitz

Top Contributor
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!
 
X

xhi2018

Gast
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
Code:
<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
Code:
<sourceDirectory>
ändern, da maven-Standard den Sourcecode dann ja unter einem Verzeichnis
Code:
...src\main\java
erwarten würde, was bei mir nicht der Fall ist...
 
Zuletzt bearbeitet von einem Moderator:

kama

Top Contributor
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)
Code:
  +-- 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:
Code:
+-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...
Code:
+-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

Top Contributor
Hi,

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 scheiß 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...

jDie Buildergebnisse
Code:
<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ß...;-(

Auch muss ich
Code:
<sourceDirectory>
ändern, da maven-Standard den Sourcecode dann ja unter einem Verzeichnis
Code:
...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
 
M

maki

Gast
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.
 
X

xhi2018

Gast
Hallo,

vielen Dank für Deine Antwort!! :applaus:
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....
Der Grund, dass sich bestehende Strukturen nicht so einfach ändern lassen (wollen) ist wohl nicht sehr gut... :(
...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;-))
Wir haben hier noch ein eigenes - in die Jahre gekommenes - Build Verfahren, dass wir gerne ablösen würden. Änderungen an der Struktur schlagen somit auch mit Aufwand auf dieses alte Verfahren durch. Diese würden wir gerne wenn irgend möglich vermeiden...
Und zum anderen ist die Anzahl der dann umzustellenden Projekte nicht gerade klein :autsch:
Ich würde mir ernsthaft überlegen die Struktur:
Code:
+-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
...
super - Mensch vielen Dank für Deinen Vorschlag. :applaus: Ich werd's mal testweise so umbauen und schauen ob ich dann damit klar komme.
Mich würde noch interessieren sind die Module "Test" auch tatsächlich Tests also Unit- oder Integrationstests?
Da ist aktuell nichts so richtig getrennt. Es sind zum einen
  • "richtige" JUnit Tests, die wirklich einzelne Units der Implementierung testen
  • dann gibt es da "dummy"-Implementierungen, die Testumgebung bereit- und nachstellen
  • und Startklassen für automatisierte Integrationstests
Ich hab Deinen Vorschlag von oben etwas für mich angepasst
Code:
+-parent pom.xml
¦
+--facility
¦  +--pom.xml
¦  +--api
¦  ¦  +--pom.xml 
¦  ¦  +--src/main/java
¦  ¦  ¦  +--org.myname.foobar.api
¦  ¦  +--src/main/resources
¦  ¦  ¦  +--lib/ini/system
¦  ¦  +--src/test/java
¦  ¦  ¦  +--org.myname.foobar.api
¦  ¦  +--src/test/resources
¦  ¦     +--...
¦  +--impl
¦  ¦  +--pom.xml 
¦  ¦  +--src/main/java
¦  ¦  ¦  +--org.myname.foobar.impl
¦  ¦  +--src/main/resources
¦  ¦  ¦  +--lib/ini/system
¦  ¦  +--src/test/java
¦  ¦  ¦  +--org.myname.foobar.impl
¦  ¦  +--src/test/resources
¦  ¦     +--...
¦  +--test
¦  ¦  + pom.xml 
¦  ¦  +--src/main/java
¦  ¦  ¦  +--org.myname.foobar.test
¦  ¦  +--src/main/resources
¦  ¦     +--...
...
wäre doch schon wesentlich "maven"-konformer, oder..? ;)
 

mvitz

Top Contributor
Naja, ob du die Arbeit jetzt darin steckst, die Projekte in die Maven Konvention zu überführen oder die Maven Konvention an eure Projekte anzupassen ist vermutlich ähnlich hoch und ja im Endeffekt einmaliger Aufwand. Du gewinnst allerdings durch die Anpassung an Maven, dass im Endeffekt jeder der sich mit Maven auskennt sofort die Projektstruktur versteht und sich diese nicht mehr aneignen muss.

Aus irgendeinem Grund muss bei euch doch auch die Entscheidung für Maven gefallen sein. Was habt ihr denn vorher genutzt?
 

kama

Top Contributor
vielen Dank für Deine Antwort!! :applaus:Der Grund, dass sich bestehende Strukturen nicht so einfach ändern lassen (wollen) ist wohl nicht sehr gut... :(
Das ist angeblich immer der Grund....Agilität ist das Stichwort...Man muss veränderungen machen, damit weiter kommt...
Wir haben hier noch ein eigenes - in die Jahre gekommenes - Build Verfahren, dass wir gerne ablösen würden. Änderungen an der Struktur schlagen somit auch mit Aufwand auf dieses alte Verfahren durch. Diese würden wir gerne wenn irgend möglich vermeiden...
Dann kann man doch die Struktur in den Java Projekten umstellen. Das delivery kann man doch so beibehalten...

  • "richtige" JUnit Tests, die wirklich einzelne Units der Implementierung testen
  • dann gibt es da "dummy"-Implementierungen, die Testumgebung bereit- und nachstellen
  • und Startklassen für automatisierte Integrationstests
Unit Tests gehören in das jeweilige Module /src/test/java...
Integrationstest sind durchaus gut in einem separaten Module aufgehoben...(siehe auch Maven Unit and Integration Test Guide - Introduction)


Code:
+-parent pom.xml
¦
+--facility
¦  +--pom.xml
¦  +--api
¦  ¦  +--pom.xml 
¦  ¦  +--src/main/java
¦  ¦  ¦  +--org.myname.foobar.api
¦  ¦  +--src/main/resources
¦  ¦  ¦  +--lib/ini/system
¦  ¦  +--src/test/java
¦  ¦  ¦  +--org.myname.foobar.api
¦  ¦  +--src/test/resources
¦  ¦     +--...
¦  +--impl
¦  ¦  +--pom.xml 
¦  ¦  +--src/main/java
¦  ¦  ¦  +--org.myname.foobar.impl
¦  ¦  +--src/main/resources
¦  ¦  ¦  +--lib/ini/system
¦  ¦  +--src/test/java
¦  ¦  ¦  +--org.myname.foobar.impl
¦  ¦  +--src/test/resources
¦  ¦     +--...
¦  +--test
¦  ¦  + pom.xml 
¦  ¦  +--src/main/java
¦  ¦  ¦  +--org.myname.foobar.test
¦  ¦  +--src/main/resources
¦  ¦     +--...
...
wäre doch schon wesentlich "maven"-konformer, oder..? ;)
Ja deutlich besser ...
Was ist das "lib/ini/system" ? Das wort "Lib" iritiert mich hier...

Aber...in dem test module ist der Package name anders als in den Modulen...am Besten bei Unit Tests immer die gleiche Package Struktur wie unter src/main/java haben...Wenn es Integrationstest sind, kann man mal von abweichen...

Apropos was mir noch so einfällt: Verwendet Ihr irgendeinen Repository Manager (Artifactory, Nexus, Archiva) ?
Gruß
Karl Heinz Marbaise
 
Zuletzt bearbeitet:
X

xhi2018

Gast
Das ist angeblich immer der Grund....Agilität ist das Stichwort...Man muss veränderungen machen, damit weiter kommt...
Dann kann man doch die Struktur in den Java Projekten umstellen. Das delivery kann man doch so beibehalten...
Der Hauptgrund gegen die Umstellung der Verzeichnisstruktur in den Projekten ist zum einen ein nicht zu unterschätzender Aufwand und zum anderen die Koexistenz mit dem bisherigen, bestehenden Build Verfahren - Eigenlösung & ANT-basierend
Unit Tests gehören in das jeweilige Module /src/test/java...
Integrationstest sind durchaus gut in einem separaten Module aufgehoben...(siehe auch Maven Unit and Integration Test Guide - Introduction)
Genau das war meine Idee für die obige Verzeichnisstruktur. Damit könnte ich die "reinen" JUnits Testfälle unter
Code:
src/test/java
von den "dummy"-Implementierungen und Startklassen für automatisierte Integrationstests in den test-Module trennen
Code:
+--test
¦  ¦  + pom.xml 
¦  ¦  +--src/main/java
¦  ¦  ¦  +--org.myname.foobar.test
¦  ¦  +--src/main/resources
¦  ¦     +--...
Die test-Module müssen erstellt werden, weil diese wiederum auf Testumgebungen installiert werden um die Anwendung zu testen.
Was ist das "lib/ini/system" ? Das wort "Lib" iritiert mich hier...
:D keine Angst, darunter sind keine "Lib"raries ... ;) Den "Job" soll mir ja maven erledigen...:cool:
Das ist eine feste Verzeichnisstruktur - wird von der Anwendung so erwartet- unterhalb der Konfigurationsdateien (xml, property, ini,...) files abgelegt werden.
Apropos was mir noch so einfällt: Verwendet Ihr irgendeinen Repository Manager (Artifactory, Nexus, Archiva) ?
Zum testen nutzen wir aktuell Nexus Open Source
 
X

xhi2018

Gast
Hallo,

nun ist mir einiges klarer geworden. Vielen Dank nochmal an alle die mir geholfen & geantwortet haben!! :toll:

Die Ursache warum in Eclipse der Maven Library Container nicht zur Verfügung gestellt wird liegt an dem Aufbau der MultiModul Projekte in "Tateinheit" mit meinem Versuch eine möglichst einfache Abhängigkeitsbeziehung hinzu bekommen, was aber so nicht zu funktionieren scheint...

Bei den Projekten handelt es sich - wie gesagt allesamt - um MultiModul Projekte mit dieser Struktur im Workspace
Code:
+-<parent_A> pom.xml <type>pom</type>             +-<parent_B> pom.xml <type>pom</type>                     
¦  +.classpath                                    ¦  +.classpath
+--<layer_1>                                      +--<layer_1>                              
¦  +--src                                         ¦  +--src                                
¦  ¦  +--<unit_a>                                 ¦  ¦  +--<unit_a>                        
¦  ¦  ¦  + modul pom.xml <type>jar</type>         ¦  ¦  ¦  + modul pom.xml <type>jar</type>                         
¦  ¦  ¦  +--org.myname.foobar.<layer1>...         ¦  ¦  ¦  +--org.myname.foobar.<layer1>...
¦  ¦  ¦                                           ¦  ¦  ¦                                  
¦  ¦  +--<unit_b>                                 ¦  ¦  +--<unit_b>                        
¦  ¦  ¦  + modul pom.xml <type>jar</type>         ¦  ¦  ¦  + modul pom.xml <type>jar</type>                      
¦  ¦  ¦  +--org.myname.foobar.<layer1>...         ¦  ¦  ¦  +--org.myname.foobar.<layer1>...
¦  ¦  ¦                                           ¦  ¦  ¦                                  
¦  ¦  ...                                         ¦  ¦  ...                                
¦  ¦                                              ¦  ¦                                     
¦  +--test                                        ¦  +--test                               
¦     + modul pom.xml <type>jar</type>            ¦     + modul pom.xml <type>jar</type>                         
¦     +--org.myname.foobar.<layer1>               ¦     +--org.myname.foobar.<layer1>      
¦                                                 ¦                                        
+--<layer_2>                                      +--<layer_2>                              
¦  +--src                                         ¦  +--src                                
¦  ¦  +--<unit_a>                                 ¦  ¦  +--<unit_a>                        
¦  ¦  ¦  + modul pom.xml <type>jar</type>         ¦  ¦  ¦  + modul pom.xml <type>jar</type>          
¦  ¦  ¦  +--org.myname.foobar.<layer2>...         ¦  ¦  ¦  +--org.myname.foobar.<layer2>...
¦  ¦  ¦                                           ¦  ¦  ¦                                  
¦  ¦  +--<unit_b>                                 ¦  ¦  +--<unit_b>                        
¦  ¦  ¦  + modul pom.xml <type>jar</type>         ¦  ¦  ¦  + modul pom.xml <type>jar</type>          
¦  ¦  ¦  +--org.myname.foobar.<layer2>...         ¦  ¦  ¦  +--org.myname.foobar.<layer2>...
¦  ¦  ¦                                           ¦  ¦  ¦                                  
¦  ¦  ...                                         ¦  ¦  ...                                
¦  ¦                                              ¦  ¦                                     
¦  +--test                                        ¦  +--test                               
¦     + modul pom.xml <type>jar</type>            ¦     + modul pom.xml <type>jar</type>                    
¦     +--org.myname.foobar.<layer2>               ¦     +--org.myname.foobar.<layer2>      
...                                               ...
Nun bestehen Abhängigkeiten über diese Module hinweg - ungefähr so:

Code:
parent_B.layer_2.unit_a
benötigt
Code:
parent_A.layer_1.unit_a
Code:
parent_B.layer_2.unit_b
benötigt
Code:
parent_A.layer_1.unit_b

Nun war mein "naiver" Ansatz der, in der
Code:
pom.xml
von parent_B
Code:
<type>pom</type>
eine Abhängigkeit zu dem parent_A Artifact
Code:
<type>pom</type>
einzutragen. Das funktioniert wohl so nicht...

Ich muss in der
Code:
pom.xml
von parent_B
Code:
<type>pom</type>
die Abhängigkeit genau zu den Artifakten
Code:
parent_A.layer_1.unit_a   <type>jar</type>
Code:
parent_A.layer_1.unit_b   <type>jar</type>
eintragen und nicht zu dem MultiModul Artifact von parent_A
Code:
<type>pom</type>

Wenn ich es dann so mache, dann wird der Maven Library Container in Eclipse dem parent_B Projekt hinzugefügt, jedoch leider mit einer Referenz auf die kompilierten jar-Artifakte von
Code:
parent_A.layer_1.unit_a
und
Code:
parent_A.layer_1.unit_b
aus meinem lokalen
maven-Repository
Code:
${HOME}/.m2/repsository/...
und nicht zu dem Source Projekt parent_A im Workspace. Source Code Änderungen im Projekt parent_A wirken sich natürlich nur dann im Projekt parent_B aus, wenn im Eclipse
Code:
mvn install
durchgeführt wird und dadurch die jar-Files im lokalen Repository aktualisiert werden... :autsch:

Möglicherweise verstehe ich noch nicht genug von maven - aber lässt sich so was in maven irgendwie abbilden..? Ich hoffe ich konnte die Situation deutlich genug erklären ...
 

Ähnliche Java Themen

Neue Themen


Oben