[ http://jira.codehaus.org/browse/MSUREFIRE-161?page=comments#action_77025 ] Ronny Naess commented on MSUREFIRE-161: ---------------------------------------
I do not blame you :-) It was I that linked the two dependencies on top. I just commented in the comment field, but I had now idea it would come out this way. Ignor may last comment and just look at my previoud post. Anyway, I have simulare problemes like the one you experienced. My test-jars (created in pom) which is to be included when running tests in other artifacts, has test resources to be used at test runtime. If i run install from top level (parent pom) my build is almost never success. My test deps is included and used in the test classpath for the first artifacts, but then it suddenly breaks even it says it is there. It breaks because test resources is not found. This is a random behavior since it later can work, and or a previous successfully built artifact may break the second time. Very frustrating all very random. It is very easy to see that this is a random error. We have resources that is the same for both main and test, that is same filenames for the resources, but different content. I list the content to screen at test runtime. Until the problem is problem is solved we have skipped the testing in maven. Did you ever solve your problems in a useful way? > VM Forking manifests itself behind HTTP proxy > --------------------------------------------- > > Key: MSUREFIRE-161 > URL: http://jira.codehaus.org/browse/MSUREFIRE-161 > Project: Maven 2.x Surefire Plugin > Issue Type: Bug > Components: classloading > Affects Versions: 2.3 > Environment: win2k, java 1.5 > Reporter: Ben Hood > Fix For: 2.3 > > Attachments: mvn_trace.txt > > > I have reason to believe that the forking behaviour of the surefire execution > has adverse effects when executed behind an HTTP proxy in combination with > DTD resolution (e.g. the loading of Spring beans). > Whilst using surefire to test a project (the acegi module from the mule > project, svn respo : http://svn.codehaus.org/mule/trunk/mule/modules/acegi , > revision 2859) I was getting DTD resolution errors (see attached trace). > I orginally posted this over at Spring: > http://opensource.atlassian.com/projects/spring/browse/SPR-2466. > Trying to get Eclipse to attach to the Maven debug process I set up (i.e. > running maven with MAVEN_OPTS="-Xdebug -Xnoagent > -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8787"), I found out > that this won't work because the plugin executing the code forks a new VM. > After telling the maven surefire-plugin not to fork with this setting: > <build> > <plugins> > <plugin> > <groupId>org.apache.maven.plugins</groupId> > <artifactId>maven-surefire-plugin</artifactId> > <configuration> > <forkMode>never</forkMode> > </configuration> > </plugin> > </plugins> > </build> > the problem with the DTD resolution from Spring went away. > Under normal circumstances, the DTD should get resolved from within the > classpath, as it is bundled in the jar. > So therefore I conclude that it is indeed a maven classloading / VM issue and > not a Spring issue as first thought. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
