Seit "Mvn Package" bei Testfällen: ClassNotFound

[Juggl3r]

Hallo,

folgendes Problem. Ich verwende eigentlich Maven in Eclipse (also das Maven Plugin von Eclipse). Wir verwenden außerdem Spring. Eine meiner Testklassen sieht beispielsweise so aus:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = { "classpath:vpmBeans-Tests.xml" })
public class TestUserDAOJDBCImpl {

	
	/**
	 * the datasource for the test database
	 */
	@Autowired
	protected DataSource datasource;
...

Früher ging alles Wunderbar, doch dann hat uns unser Tutor gesagt, das wir es auch mit Maven direkt aus der Konsole starten können müssen.

Seitdem ich in der Konsole "mvn package" eingegeben habe, bekomme ich jetzt bei den ganzen Testfällen immer folgende Fehlermeldung:

"2012-12-30 23:50:36,842 [main]: org.springframework.beans.factory.xml.XmlBeanDefinitionReader - INFO : Loading XML bean definitions from class path resource [vpmBeans-Tests.xml]
2012-12-30 23:50:36,852 [main]: org.springframework.context.support.GenericApplicationContext - INFO : Refreshing org.springframework.context.support.GenericApplicationContext@1dcb677: startup date [Sun Dec 30 23:50:36 CET 2012]; root of context hierarchy
2012-12-30 23:50:36,860 [main]: org.springframework.beans.factory.support.DefaultListableBeanFactory - INFO : Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@b35c53: defining beans [dataSource,categoryDao,userDao,moderatorDao,administratorDao,userService,movie0,movie1,dateFormat,org.springframework.context.annotation.internalConfigurationAnnotationProcessor,org.springframework.context.annotation.internalAutowiredAnnotationProcessor,org.springframework.context.annotation.internalRequiredAnnotationProcessor,org.springframework.context.annotation.internalCommonAnnotationProcessor,org.springframework.context.annotation.ConfigurationClassPostProcessor$ImportAwareBeanPostProcessor#0]; root of factory hierarchy
2012-12-30 23:50:36,868 [main]: org.springframework.beans.factory.support.DefaultListableBeanFactory - INFO : Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@b35c53: defining beans [dataSource,categoryDao,userDao,moderatorDao,administratorDao,userService,movie0,movie1,dateFormat,org.springframework.context.annotation.internalConfigurationAnnotationProcessor,org.springframework.context.annotation.internalAutowiredAnnotationProcessor,org.springframework.context.annotation.internalRequiredAnnotationProcessor,org.springframework.context.annotation.internalCommonAnnotationProcessor,org.springframework.context.annotation.ConfigurationClassPostProcessor$ImportAwareBeanPostProcessor#0]; root of factory hierarchy
2012-12-30 23:50:36,868 [main]: org.springframework.test.context.TestContextManager - ERROR: Caught exception while allowing TestExecutionListener [org.springframework.test.context.support.DependencyInjectionTestExecutionListener@6cd243] to prepare test instance [at.tuwien.group2.vpm.dao.TestUserDAOJDBCImpl@a38527]
java.lang.IllegalStateException: Failed to load ApplicationContext
at org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:157)
at org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:109)
at org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:75)
at org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:321)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:211)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:288)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:290)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:231)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: org.springframework.beans.factory.CannotLoadBeanClassException: Cannot find class [at.tuwien.group2.vpm.service.UserServiceImpl] for bean with name 'userService' defined in class path resource [vpmBeans-Tests.xml]; nested exception is java.lang.ClassNotFoundException: at.tuwien.group2.vpm.service.UserServiceImpl
at org.springframework.beans.factory.support.AbstractBeanFactory.resolveBeanClass(AbstractBeanFactory.java:1262)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.predictBeanType(AbstractAutowireCapableBeanFactory.java:576)
at org.springframework.beans.factory.support.AbstractBeanFactory.isFactoryBean(AbstractBeanFactory.java:1331)
at org.springframework.beans.factory.support.AbstractBeanFactory.isFactoryBean(AbstractBeanFactory.java:897)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:590)
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:918)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:469)
at org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:103)
at org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:1)
at org.springframework.test.context.support.DelegatingSmartContextLoader.loadContext(DelegatingSmartContextLoader.java:228)
at org.springframework.test.context.TestContext.loadApplicationContext(TestContext.java:124)
at org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:148)
... 24 more
Caused by: java.lang.ClassNotFoundException: at.tuwien.group2.vpm.service.UserServiceImpl
at java.net.URLClassLoader$1.run(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at org.springframework.util.ClassUtils.forName(ClassUtils.java:258)
at org.springframework.beans.factory.support.AbstractBeanDefinition.resolveBeanClass(AbstractBeanDefinition.java:417)
at org.springframework.beans.factory.support.AbstractBeanFactory.doResolveBeanClass(AbstractBeanFactory.java:1283)
at org.springframework.beans.factory.support.AbstractBeanFactory.resolveBeanClass(AbstractBeanFactory.java:1254)
... 35 more"


und das bei jedem Testfall.
Anfangs konnte ich das Programm auch nicht mehr in Eclipse starten, da er meinte, er findet Main.java nicht mehr, da habe ich dann den Src Ordner vom Build Path gelöscht und wieder hinzugefügt. Aber die Testfälle laufen trotzdem so immer noch nicht durch.

Auch auf der Konsole bei "mvn package" bekomme ich lauter ClassNotFound Exceptions bei den Testfällen. Und auch wenn ich java -jar archiv.jar mache bei dem erstellen Archiv, bekomme ich ClassNotFound Exception.


Kann mir bitte jemand helfen und sagen, was ich da falsch gemacht habe? Mein ganzes Projekt ist gerade zerstört und ich versuche schon seit Stunden verzweifelt es wieder zum Laufen zu bekommen, weiß aber nicht einmal, nach was genau ich da googeln soll......
Falls pom.xml oder andere Infos gebraucht werden, bitte einfach Posten, aber ich hab nicht einmal eine Ahnung welche Infos bei dem Problem helfen könnten....

Wäre euch wirklich extrem dankbar, wenn ihr mir da helfen könnt !


edit:
Also soweit ich das verstanden habe, ist "classpath" nicht mehr gesetzt und deshalb wird vpmBeans-Tests.xml nicht mehr gefunden. Aber wie setze ich classpath wieder? Und warum ist es gelöscht worden?

 

[kama]

Hi,
wo liegen die Datein wie z.B. vpmBeans-Tests.xml ?

Weiterhin fällt mir auf, dass anhand des Namens TestUserDAOJDBCImpl man vermuten kann, dass das keine Unit Tests mehr sind sondern Integrationstest. Abgesehen davon bei einem Test testet man gegen das Interface und nicht gegen eine spezifische Implementierung...

Gruß
Karl-Heinz Marbaise

 

[deetee]

Vesuch mal deine pom.xml mit dem <resource> Element zu erweitern:
[XML]
<build>
...
<resources>
<resource>
<directory>src/main/resources</directory>
</resource>
<resource>
<directory>src/test/resources</directory>
</resource>
...
</resources>
...
</build>
[/XML]

Damit sollte die vpmBeans-Tests.xml wieder gefunden werden, wenn Maven über die Konsole ausgeführt wird. Eclipse benötigt das nicht.

 

[kama]

Hi,

Vesuch mal deine pom.xml mit dem <resource> Element zu erweitern:
[XML]
<build>
...
<resources>
<resource>
<directory>src/test/resources</directory>
</resource>
...
</resources>
...
</build>
[/XML]

Das sind die defaults von Maven. Das braucht man nicht und sollte man auch nicht definieren, da es in Maven bereits definiert ist (Convention over Configuration)...und das hat auch nichts mit Eclipse / Maven Command line zu tuen da Eclipse (M2e) einen Maven Embedder verwendet der genau das gleiche macht...

Gruß
Karl-Heinz Marbaise

 

[deetee]

Ok, wenn das nichts bringt, würde ich mal die Ausgabe analysieren von:

mvn help:effective-pom

Das ist die finale pom Konfiguration, die letztlich für dien Projekt greift. Da einfach mal nach fehlenden/vermissten Elementen schauen oder auf falsche Pfade prüfen.

 

[kama]

Hi,

...
mvn help:effective-pom

Das ist die finale pom Konfiguration, die letztlich für dien Projekt greift. Da einfach mal nach fehlenden/vermissten Elementen schauen...

Welche fehlenden Elemente ? Es gibt für alle Elemente entsprechende Defaults eben Konventionen......

Gruß
Karl-Heinz Marbaise

 

[Juggl3r]

Hallo,

also vpmBeans-Tests.xml sowie alle anderen Bean Files (habe eines für Tests und ein normales) liegen direkt im Src Ordner. Den Src Ordner habe ich direkt per Rechtsklick und addToBuildPath hinzugefügt.

Ich probiers einmal in den Resource Ordner zu verschieben, bin aber gerade nicht auf meinem Laptop, kann es vondaher leider erst morgen Testen. Aber vielen Dank auf jeden Fall!

Achja bezüglich der Testklasse. Ja wir testen nur auf dem Interface.... die Namensgebung ist wirklich schlecht, das ändere ich noch. Eigentlich sollten es keine Integration Tests sein, sondern Unit Tests. wir verwenden DBUnit zum testen. Da können wir in XML Files den Zustand vor dem Test und nach dem Test angeben.

lg und danke nochmal euch allen, ich melde mich morgen nochmals ob es funktioniert hat.

 

[kama]

Hi,

Hallo,

also vpmBeans-Tests.xml sowie alle anderen Bean Files (habe eines für Tests und ein normales) liegen direkt im Src Ordner. Den Src Ordner habe ich direkt per Rechtsklick und addToBuildPath hinzugefügt.

Wenn Maven im Spiel ist die IDE raus...somit Konfiguration über das POM File und nichts mehr über die IDE...

Deshalb immer die Kommandozeile Testen..die hat recht ;-)

Das für den produktiven Einsatz gehört unter src/main/resources während das für den Test src/test/resources gehört...

In Maven gibt es die Konvention im src/main/java gehören wie der Name sagt nur Java Source Files...nichts anderes...

Ich probiers einmal in den Resource Ordner zu verschieben, bin aber gerade nicht auf meinem Laptop, kann es vondaher leider erst morgen Testen. Aber vielen Dank auf jeden Fall!

..Klar kein Problem...

Achja bezüglich der Testklasse. Ja wir testen nur auf dem Interface.... die Namensgebung ist wirklich schlecht, das ändere ich noch. Eigentlich sollten es keine Integration Tests sein, sondern Unit Tests. wir verwenden DBUnit zum testen. Da können wir in XML Files den Zustand vor dem Test und nach dem Test angeben.

Das was ich erwartet habe. Es sind Integrations Tests und keine Unit Tests. Ein Unit Test ist per definition unabhängig von allen anderen Klassen und auch von anderen Resources was in diesem Falle nicht gegeben ist.....

Gruß
Karl-Heinz Marbaise

 

[Juggl3r]

Hm ok?

Ja ich hab bei uns in den Folien auch öfters gelesen, das Unit Tests unabhängig sein sollen. Aber wie Testest du dann DAO's mit Unit Tests? So das sie unabhängig sind?
z.b. eine addUser Methode? Wenn ich keine DBUNit verwende und kein JDBC in der Klasse, wie teste ich soetwas? Die negativen Fälle sind einfach (einfach schauen ob exception geworfen wird), aber wie prüfe ich das Positive? Weil wenn ich ein getAll() mache und dann schaue ob nach dem addUser das getAll() mir eine Liste mit Size+1 returned, dann ist das doch auch kein Unit Test mehr oder? Weil man ja immer nur 1 Methode testen sollte?

Zurzeit haben wir es so, das wir die DAO's gegen das Interface mit DBUnit Testen. Die Service Schicht testen wir mit Mockito.

lg und danke für die Infos.

 

[kama]

Hi,

Es ist von der Begrifflichkeit zu unterscheiden, ob ich einen Unit Tests oder einen Integrationstest habe...man solle da schon auf die Bezeichnungen achten...

Der Punkt im Zusammenhang mit Integrationstests in Maven ist einfach, dass Integrationstest eben in der integration-test phase (life cycle) laufen und eben nicht in der test phase. Die integrations-test phase ist nach der Package phase weiterhin sollte man integrationstests eben XYZIT.java nennen. Oft ist es in Maven auch sinnvoll ein eigenes Module zu erstellen. Damit ist bereits am Namen erkennbar, dass es sich um einen Integrations Test handelt. Weiterhin wird die Ausführung vom maven-failsafe-plugin durchgeführt während die Unit Tests vom maven-surefire-plugin ausgeführt werden.

Die Idee der Trennung ist in der Laufzeit begründet. Unit Tests sind unabhängig und schnell (auch eine große Menge z.B. 1000 Unit Tests) brauchen nur wenige Sekunden eventuell mal 10-20 Sekunden...sprich, um die Feedback Zeit möglichsts kurz zu halten.

Aber Integrations tests laufen unter Umständen wesentlich länger Minuten oder gar Stunden ...ich habe schon Web-IT's geschrieben die 2 Stunden gelaufen sind...

Wenn eine saubere Trennung gemacht wird, dann ist es auch einfach möglich im Rahmen einer Continous Integration die Unit Tests z.B. bei jedem checkin laufen zu lassen aber die Integrations Testen beispielsweise nur einmal in der Nacht etc.

Gruß
Karl-Heinz Marbaise

 

[Juggl3r]

Danke für die vielen Infos und Tipps.

Ich habe die Beans Files jetzt nach resources verschoben, aber irgendwie will es immer noch nicht so will... die Tests schlagen immer noch fehl. Ich habe anbei einen screenshot von eclipse (mit der Ordner Struktur) + den Output von "mvn package" + das pom.xml File. wäre echt toll, wenn jemand da nochmal kurz drüber schauen könnte und mir sagen könnte, was da falsch ist.


Und wenn ich das erstellte .jar File ausführen will, bekomme ich auch noch folgenden Fehler:

java.lang.NoClassDefFoundError: org/springframework/context/ApplicationContext
	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
	at java.lang.Class.getMethod0(Unknown Source)
	at java.lang.Class.getMethod(Unknown Source)
	at sun.launcher.LauncherHelper.getMainMethod(Unknown Source)
	at sun.launcher.LauncherHelper.checkAndLoadMain(Unknown Source)
Caused by: java.lang.ClassNotFoundException: org.springframework.context.ApplicationContext
	at java.net.URLClassLoader$1.run(Unknown Source)
	at java.net.URLClassLoader$1.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(Unknown Source)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	... 6 more
Exception in thread "main"

Das .jar File enthält auch die gesamten Libs nicht, ich denke es liegt daran.....

lg und nochmals großen Dank für die bisherige Hilfe.


ps:
Wenn ein Kollege beim gleichen Branch versucht die tests per mvn package auszuführen, gehen sie bei ihm?

 

[kama]

Hi,

hast Du dir mal die Nachricht:

Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from class path resource [test/resources/testBeansTag.xml]; nested exception is java.io.FileNotFoundException: class path re
source [test/resources/testBeansTag.xml] cannot be opened because it does not exist^M

genau angeschaut ?

Abgesehen sind einige Angaben in der pom.xml doch wie soll ich sagen, ein wenig ungewöhnlich....

1. Die version von maven-surefire-plugin (2.5) ist uralt.. (aktuelle 2.13).
Die Konfiguration hier skipTest auf false zu setzten macht keinen Sinn, da das der default ist. testFailureIgnore auf
true ist auch nicht wirklich gut (sollte man nicht machen). Der ForkMode auf once zu setzen ist auch nicht gerade
sinnvoll, da das auch der Default ist.

2. Wozu wird das maven-dependency-plugin verwendet ?

3. Der Reporting Bereich würde ich zuerst einmal schlicht rausnehmen und erst mal alles sauber ans laufen bringen, bevor ich
mir gedanken zum Thema Reporting mache. (maven-compiler-plugin gehört da nicht hin und ist auch uralt 3.0.

4. Bei der Dependency

[XML]
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>2.5.6.SEC03</version>
</dependency>
[/XML]
habe ich so meine Zweifel, da der Rest von Spring mit 3.1.2.RELEASE angegeben ist ?

5. Bei der Dependency

[XML]
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-all</artifactId>
<version>1.9.5-rc1</version>
</dependency>
[/XML]
würde ich zu einen eine aktuelle Release nehmen (1.9.5) und nicht mehr RC1 weiterhin würde ich bei Mockito einen Scope Test setzten, da mockito als Mock Framework in der Regel nur bei Tests zum Einsatz kommt..

6. Das Gleiche gillt auch für (siehe 5.)

[XML]
<dependency>
<groupId>org.dbunit</groupId>
<artifactId>dbunit</artifactId>
<version>2.4.8</version>
</dependency>
[/XML]
Ebenfalls Scope Test...

Weiterhin macht die Verwendung einer Reinen API wie hier

[XML]
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.6.6</version>
</dependency>
[/XML]
nur Sinn, wenn man auch mal einen Implementierung dazu aufnimmt..siehe Doku dazu
...

Edit: Apropos den Screenshot von Eclipse Zeigt mir Code der so zum Testen unter Maven nicht wirklich der richtige Weg ist...Da wird per

..
File file = new File("./src/test/resources/...");

Besser mit Resourcen arbeiten.

..
InputStream is = this.getClass().getResourceAsStream("/nameYouWantToUse.xml");
...

Abgesehen erwecken die Ausgaben im Fenster von Eclipse nicht den Eindruck, dass die Tests in Eclipse laufen...Da gibt es Exceptions...!

Gruß
Karl-Heinz Marbaise

 

[Juggl3r]

Puh danke, werd das alles mal abarbeiten gehen....
Die Tests laufen jetzt aber, in den Testfällen wurden Exceptions provoziert und das in der Console waren nur die Logmeldungen, das eine Exception aufgetreten ist (so wie es im Testfall erwartet wurde).

Danke für die ganzen Tipps.

edit:
Hm das mit dem Resourcen kannst du mir das vielleicht nochmals kurz erklären? Warum man da kein File nehmen soll sondern InputStream? Den Code so habe ich glaube ich direkt von DBUnit Seite.


Das Try-Catch gehört eigentlich auch im Testfall weg....

edit2:
Achja, das pom.xml file war total zusammengegoogelt - ich denke das hat man auch sehr stark gemerkt an deinem obigen Post. Ist halt das aller erste mal das wir alle Maven, Spring, GUI programmierung, DBUnit, Mockito, logging, ... bzw. eigentlich all die Technologien verwenden und vondaher ziemlich viel aufeinmal.

 

[kama]

Hi,

wenn die Exception absicht sind, dann solltest Du die Tests so schreiben, dass die das auch erwarten...Logging sollte man entsprechend konfigurieren...

@Test(expected = WasWeissIchFuerEineException.class)
....

Hier würde ich mir aber schon überlegen TestNG anstatt JUnit zu verwenden...


Weiterhin würde ich dafür sorgen, nur im Falle eines Fehler Ausgaben erzeugen, wenn etwas schiefläuft...und ansonsten keinerlei Ausgaben erzeugt werden...
Diese Ausgaben "CHECK..." sind käse...wenn der Test fehlschlägt, kann ich im Test Report (von Jenkins etc.) nachschauen welcher Test genau auf die Nase gefallen ist...

Edit: Hier der Code von DBUnit:

  return new FlatXmlDataSetBuilder().build(new FileInputStream("dataset.xml"));

Dann sollte es OHNE Probleme möglich sein so etwas zu machen:

  return new FlatXmlDataSetBuilder().build(this.getClass().getResourceAsStream("/testXYZ.xml")));

Gruß
Karl-Heinz Marbaise

 

[Juggl3r]

Hm danke.

Ja das mit Expect=Exception haben wir eh gemacht, das sieht man aber auf dem Screenshot nicht.

In der DAO selbst wird bevor die exception geworfen wird die Fehlermeldung ausgegeben, deshalb wurde sie angezeigt. Die Logausgaben gehören übirgens nicht zu dem Teil des Sourcecodes, den man sieht.

Das TestNG muss ich mir nochmal ansehen, wir haben aber von der Lehrveranstaltung aus die Technologien (also Grundtechnologien) vorgegeben bekommen, daher junit.

Wie gesagt, sind halt sehr viele Technologien und Programme auf einmal, daher bin ich immer für alle Tipps offen und froh
Danke dir auf jeden Fall wirklich für die großartige Hilfe!

 

[deetee]

Ist dein Problem nun gelöst? Wenn ja, woran lag es genau?

Denn im ersten Post meintest du, dass die vpmBeans-Tests.xml nicht gefunden wird, was laut deiner Exception aber nicht der Fall war. Es wurde Beans aus dieser XML Datei nicht gefunden.

In deinem Post #11 wird allerdings nun die testBeansTag.xml Datei nicht mehr gefunden, was der Auszug von kama auch zeigt.

Das ganze ist letztlich weniger ein Problem von Maven, sondern vom Programmcode (Laden von Resources) und von der IDE (Buildpath Konfiguration).

Es wurde erst zum "Maven-Problem" für dich, als du das Projekt außerhalb der IDE bauen wolltest. Das lag dann wohl an der nicht standardkonformen Maven Verzeichnisstruktur, die du nun ja angepasst hast.

Falls das so bisher alles stimmt, verstehe ich nur nicht, wieso in deinem ersten Post die testBeansTag.xml Datei gefunden wurde?

Nicht ganz leicht bei solchen Projekten, die gegen Standards und Konventionen verstoßen (bzw. einiges anders machen), den Durchblick zu bekommen.

PS:
Nur zur Info, es gibt zu deinem Problem einige Einträge bei Google, u.a. dieser hier.
Spring Unit tests – Maven – Application Context not loading | Shaun Hare – Myrtle Says

 

[Juggl3r]

Also ehrlich gesagt bin ich mir nicht ganz sicher, was das Problem war. Eines der Probleme war auf jeden Fall, dass ich meinen Service von "userServiceImpl" auf "userManagementServiceImpl" umbenannt habe, da ich dort auch moderatoren und administratoren Support reingegeben habe, allerdings habe ich das nicht in dem Test-Beans XML File geändert. Die Änderung habe ich kurz davor gemacht, weshalb in Eclipse die Testfälle nicht mehr funktioniert haben. Gleich danach habe ich das Maven package gemacht, weshalb ich dachte, das es an Maven liegt (bzw. einer aus unserer Gruppe auch mvn Package gemacht hatte und danach seine Testfälle in Eclipse nicht mehr funktioniert haben. Daher dachte ich, dass es das gleiche ist...).

Auf der Konsole gehen die Testfälle bei mir immer noch nicht, wenn allerdings ein Teammitglied bei mir es probiert, geht es. Das werden wir uns Freitags ansehen, wenn wir uns treffen (genauso wie das pom.xml File aufräumen).

Allerdings ist das Erstellte .jar File noch ausführbar. Sollten nicht normalerweise sämtliche Libs in dem Jar File enthalten sein? In unserem sind nur die Klassen enthalten.


Wir müssen relativ bald mal den Code herzeigen, vondaher bin ich gerade voll damit beschäftigt weitere Features einzubauen und deshalb wollte ich erst Freitags mich um die Maven Probleme (bzw. Architektur und Ordneraufbau usw.) kümmern, damit ich bis dahin zumindest einigermaßen viel an Code zum herzeigen hätte (bei dem bug lösen brauche ich sonst nur sehr viel Zeit und kann dann nur relativ wenig herzeigen....). Ich melde mich auf jeden Fall Freitags nochmals, sobald ich die Lösung gefunden habe (oder weiter am Verzeifeln bin... ).

lg

 

[deetee]

Ok, also letztlich lag es am nicht angepassten Bean Name in der XML. Zumindest was das Ausführen in Eclipse angeht.

Die Probleme über die Konsole kommen immernoch vom Programmcode, bzw. wie die Ressourcen geladen werden.
Das Problem besteht übrigens auch, wenn mal ein CI Server wie Jenkins euer Projekt überwachen soll. Es lohnt sich also den Code dahingehend zu ändern, dass Ressourcen aus dem Classpath geladen werden.