ability to add dependency to jvm's classpath rather in surefirebooter classloader

Attached are 2 patches for surefire-plugin and surefire-booter. Feel free to change the new field name.

This patch adds project dependency jars into jvm 's -classpath param conditioning by an new boolean flag

The boot class path is not the same classpath as -classpath, which one are you really after here?

I'm pretty sure the boot class path is an optional class path (it might be the same as -classpath).

I am after placing the project dedendencies on the -classpath list of the fork command

My surefire plugin would look like this

<dependendcies>
<!-- need this on JVM -classpath list -->
</dependencies>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<forkMode>once</forkMode>

<workingDirectory>${project.build.directory}</workingDirectory>

<argLine>-Xrunpri:${basedir}/src/test/resources/optimizeit.xml -Xbootclasspath/p:myboot.jar</argLine>

<allowClasspathElementsOnCommandline>true</allowClasspathElementsOnCommandline>
</configuration>
</plugin>

myboot.jar after booting up needs to reference some other class in my project dependencies expected on -classpath

The problem is that if the classpath makes the command line too long it will fail

most of the time, the normal processing of classpath after JVM is loaded shoudl work, however in my use case,
due the relationship between the jvm's bootclasspath and -classpath, my patch solve the immedidate need.

I would urge to get my patch accepted unless it is radically changing the architechure of the plugin

I still don't understand what you're after here, you're saying something about the boot class path and something about the -classpath.

How will making a URLClassLoader containing all the JAR files different from adding them to -classpath? The ability to add stuff to the boot strap class path is useful, but you need to explain why you need to add stuff to -classpath.

And, we can't be expected to add stuff just beacuse it fixes your problem. That will lead to unwanted complexity and feature creep that we will have to maintain.

if Dan could provide an use case that breaks right now it'd be great

Ok, let me try to rephase in details so see it makes sense.

In my fork mode sample configuration, myboot.jar must be loaded via -Xbootclasspath/p:myboot.jar command line.
myboot.jar then references, at boot time, some other classes in my project dependency and FAILS since my dependendencies
are not loaded yet. They are loaded only after the JVM is fully constructed ( see SureFireBooter's main method ).

The solution is to place my dependencies as part of java.exe 's -classpath list which currently contain only the sure-fire's plugin dependencies
(ie surefire-api, surefire-booter, etc)

here is my jvm command line example
java.exe -Xrunpri:${basedir}/src/test/resources/optimizeit.xml -Xbootclasspath/p:myboot.jar -classpath <mydependencies> ...

I would still like to understand the real use case that you have here.

Will classes in the bootstrap classloader really load stuff from the system classpath (i.e. the one given with -classpath)?

Instead of adding all of the dependencies to the -classpath it might be better to be able to give a set of artifacts to add. Ideally it should be given a set of artifacts and use Maven's code to resolve the rest of the required artifacts.

Yes, classes in the bootstrap classloader really load stuff from the system classpath

I am fine with the idea of allowing only a set of selected artifacts to add, it is a better solution to minimize the problem of long command line

MSUREFIRE-121.plugin.patch2 allows selective dependency to be place on JVM -classpath value.

There is no need to change surefire component

Please disregard MSUREFIRE-121.plugin.patch and MSUREFIRE-121.booter.patch

MSUREFIRE-121.plugin.patch3 contains the check for NPE. Final one I hope

The main question here is why do you need to add classes to the boot classpath?

It uses an -X option, which is JRE specific; it's better not to fiddle with the boot classpath.

I'm sure there's a perfectly legal usecase (java.lang.instrument stuff maybe?), but what is it?

It is Borland's Optimizeit memory and cpu profilers

Fixed in revision 488508. Added useSystemClassloader parameter that puts ALL test classpath elements
in the system classloader. This is the only safe way to do it.

Dont think Kenney's fix works. i specificly enable <useSystemClassLoader>true</useSystemClassLoader>
but my driver still encounter class not found.

Will see if I can come up with a small test case

-D

The code shows that when useSystemClassLoader is enable, the generated command use -jar argument instead of -classpath which is wrong

Start with this line to see more details

Commandline cli = forkConfiguration.createCommandLine( bootClasspath, useSystemClassLoader );

looking further, Kenney's approach of using java -jar to load a temp jar with Main-Class and Class-Path setup in manifest file is correct.
However, it is currently not working here is error when attempt to enable loadSystemClassLoader=true
<error>
[INFO] Building jar: C:\DOCUME~1\dtran\LOCALS~1\Temp\surefirebooter45181.jar
java.lang.NoClassDefFoundError: org/apache/maven/surefire/booter/SurefireBooter
Exception in thread "main"
</error>

here is the manifes file:

Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: 1.5.0_08-b03 (Sun Microsystems Inc.)
Main-Class: org.apache.maven.surefire.booter.SurefireBooter
Class-Path: c:\dev\maven-repo\org\apache\maven\surefire\surefire-boote
r\2.4-SNAPSHOT\surefire-booter-2.4-SNAPSHOT.jar c:\dev\maven-repo\org
\codehaus\plexus\plexus-archiver\1.0-alpha-7\plexus-archiver-1.0-alph
a-7.jar c:\dev\maven-repo\junit\junit\3.8.1\junit-3.8.1.jar c:\dev\ma
ven-repo\org\codehaus\plexus\plexus-container-default\1.0-alpha-8\ple
xus-container-default-1.0-alpha-8.jar c:\dev\maven-repo\classworlds\c
lassworlds\1.1-alpha-2\classworlds-1.1-alpha-2.jar c:\dev\maven-repo\
org\codehaus\plexus\plexus-utils\1.1\plexus-utils-1.1.jar c:\dev\mave
n-repo\org\apache\maven\surefire\surefire-api\2.4-SNAPSHOT\surefire-a
pi-2.4-SNAPSHOT.jar c:\dev\maven-repo\commons-lang\commons-lang\2.1\c
ommons-lang-2.1.jar C:\dev\mojo\maven-native\maven-native-api\target\
classes/ C:\dev\mojo\maven-native\maven-native-api\target\test-classe
s/ c:\dev\maven-repo\junit\junit\3.8.1\junit-3.8.1.jar c:\dev\maven-r
epo\org\codehaus\plexus\plexus-container-default\1.0-alpha-9\plexus-c
ontainer-default-1.0-alpha-9.jar c:\dev\maven-repo\classworlds\classw
orlds\1.1-alpha-2\classworlds-1.1-alpha-2.jar c:\dev\maven-repo\org\c
odehaus\plexus\plexus-utils\1.1\plexus-utils-1.1.jar c:\dev\maven-rep
o\bcel\bcel\5.1\bcel-5.1.jar c:\dev\maven-repo\org\apache\maven\maven
-plugin-api\2.0\maven-plugin-api-2.0.jar

The manifest looks good, but I am still not able to find out while it encounters
class not found exception thou

still looking....

I have the same problem with "useSystemClassLoader" and also get
java.lang.NoClassDefFoundError: org/apache/maven/surefire/booter/SurefireBooter

Does this feature work at all?

I want to run a TestCase for a Google-Web-Toolkit Client. This does NOT work with the classloader isolation.

So what is the workaround here? Use maven-run-plugin instead of surefire?

It works perfectly here, but it may be a windows issue.
Could you please provide a testcase I can run here?

I am still getting the following when

<useSystemClassLoader>true</useSystemClassLoader>

[INFO] [surefire:test]
[INFO] Surefire report directory: C:\Source\test\trunk\core\target\surefire-repo
rts
[INFO] Building jar: c:\temp\surefirebooter37241.jar
java.lang.NoClassDefFoundError: org/apache/maven/surefire/booter/SurefireBooter
Exception in thread "main"
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------

Is there a fix for work around.

Currently using XP

I have vendor required classes in jre/lib/ext

Regards,
Abe

I've also encountered the need to load resources from the classpath in unit tests so gave the latest plugin (2.3) and the <useSystemClassLoader> configuration a try but ran into this error;

[INFO] Surefire report directory: c:\Documents and Settings\nick\workspace\DataF
eeds\target\surefire-reports
[INFO] Building jar: c:\DOCUME~1\nick\LOCALS~1\Temp\surefirebooter59155.jar
java.lang.NoClassDefFoundError: org/apache/maven/surefire/booter/SurefireBooter
Exception in thread "main"
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE

I'm using XP.

this will be more helpful perhaps

[DEBUG] C:\Documents and Settings\nick\.m2\repository\commons-pool\commons-poo
l\1.3\commons-pool-1.3.jar
[DEBUG] Setting system property [localRepository]=[C:/Documents and Settings/nic
k/.m2/repository]
[DEBUG] Setting system property [basedir]=[c:\Documents and Settings\nick\worksp
ace\DataFeeds]
[DEBUG] Using JVM: c:\Java\jdk1.5.0_11\jre\bin\java
[INFO] Surefire report directory: c:\Documents and Settings\nick\workspace\DataF
eeds\target\surefire-reports
[INFO] Building jar: c:\DOCUME~1\nick\LOCALS~1\Temp\surefirebooter63991.jar
Forking command line: c:\Java\jdk1.5.0_11\jre\bin\java -jar c:\DOCUME~1\nick\LOC
ALS~1\Temp\surefirebooter63991.jar c:\DOCUME~1\nick\LOCALS~1\Temp\surefire63989t
mp c:\DOCUME~1\nick\LOCALS~1\Temp\surefire63990tmp
java.lang.NoClassDefFoundError: org/apache/maven/surefire/booter/SurefireBooter
Exception in thread "main"
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------

Ok I think I've found the issue here. It is the way in which the surefire jar manifest is being created.

The created temporary surefire jar has no classes, but uses a class path entry in the manifest to point to the maven repository so that the system class loader is able to pre-load the dependencies (including the stated SurefireBooter for one). However on Windows, this manifest illegally contains paths with drive letters.

Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: 1.5.0_11-b03 (Sun Microsystems Inc.)
Main-Class: org.apache.maven.surefire.booter.SurefireBooter
Class-Path: C:\Documents and Settings\nick\.m2\repository\org\codehaus
\plexus\plexus-archiver\1.0-alpha-7\plexus-archiver-1.0-alpha-7.jar C
:\Documents and Settings\nick\.m2\repository\junit\junit\3.8.1\junit-
3.8.1.jar C:\Documents and Settings\nick\.m2\repository\org\apache\ma
ven\surefire\surefire-api\2.3\surefire-api-2.3.jar C:\Documents and S
ettings\nick\.m2\repository\org\codehaus\plexus\plexus-container-defa
ult\1.0-alpha-8\plexus-container-default-1.0-alpha-8.jar C:\Documents
and Settings\nick\.m2\repository\classworlds\classworlds\1.1-alpha-2
\classworlds-1.1-alpha-2.jar C:\Documents and Settings\nick\.m2\repos
itory\org\codehaus\plexus\plexus-utils\1.1\plexus-utils-1.1.jar C:\Do
cuments and Settings\nick\.m2\repository\commons-lang\commons-lang\2.
1\commons-lang-2.1.jar C:\Documents and Settings\nick\.m2\repository\
org\apache\maven\surefire\surefire-booter\2.3\surefire-booter-2.3.jar
c:\Documents and Settings\nick\workspace\DataFeeds\target\classes/ c
:\Documents and Settings\nick\workspace\DataFeeds\target\test-classes
/ C:\Documents and Settings\nick\.m2\repository\com\metoceanengineers
\plot-tools\1.1.0\plot-tools-1.1.0.jar C:\Documents and Settings\nick
\.m2\repository\mysql\mysql-connector-java\5.0.6\mysql-connector-java
-5.0.6.jar C:\Documents and Settings\nick\.m2\repository\org\objectwe
b\carol\carol\2.0.5\carol-2.0.5.jar C:\Documents and Settings\nick\.m
2\repository\backport-util-concurrent\backport-util-concurrent\3.0\ba
ckport-util-concurrent-3.0.jar C:\Documents and Settings\nick\.m2\rep
ository\org\mule\transports\mule-transport-jms\1.4.1\mule-transport-j
ms-1.4.1.jar C:\Documents and Settings\nick\.m2\repository\org\apache
\geronimo\specs\geronimo-jms_1.1_spec\1.0.1\geronimo-jms_1.1_spec-1.0
.1.jar C:\Documents and Settings\nick\.m2\repository\commons-discover
y\commons-discovery\0.2\commons-discovery-0.2.jar C:\Documents and Se
ttings\nick\.m2\repository\org\mule\mule-core\1.4.1\mule-core-1.4.1.j
ar C:\Documents and Settings\nick\.m2\repository\commons-lang\commons
-lang\2.1\commons-lang-2.1.jar C:\Documents and Settings\nick\.m2\rep
ository\com\metoceanengineers\rems-exporter\1.0.6\rems-exporter-1.0.6
.jar C:\Documents and Settings\nick\.m2\repository\org\mule\transport
s\mule-transport-file\1.4.1\mule-transport-file-1.4.1.jar C:\Document
s and Settings\nick\.m2\repository\org\mule\modules\mule-module-jotm\
1.4.1\mule-module-jotm-1.4.1.jar C:\Documents and Settings\nick\.m2\r
epository\commons-beanutils\commons-beanutils\1.7.0\commons-beanutils
-1.7.0.jar C:\Documents and Settings\nick\.m2\repository\com\metocean
engineers\netcdfjavalib\2.3.0\netcdfjavalib-2.3.0.jar C:\Documents an
d Settings\nick\.m2\repository\log4j\log4j\1.2.13\log4j-1.2.13.jar C:
\Documents and Settings\nick\.m2\repository\junit\junit\3.8.2\junit-3
.8.2.jar C:\Documents and Settings\nick\.m2\repository\jcmdline\jcmdl
ine\1.0.1\jcmdline-1.0.1.jar C:\Documents and Settings\nick\.m2\repos
itory\org\apache\geronimo\specs\geronimo-jta_1.0.1B_spec\1.0.1\geroni
mo-jta_1.0.1B_spec-1.0.1.jar C:\Documents and Settings\nick\.m2\repos
itory\commons-net\commons-net\1.4.1\commons-net-1.4.1.jar C:\Document
s and Settings\nick\.m2\repository\jdom\jdom\1.0\jdom-1.0.jar C:\Docu
ments and Settings\nick\.m2\repository\org\slf4j\jcl104-over-slf4j\1.
3.1\jcl104-over-slf4j-1.3.1.jar C:\Documents and Settings\nick\.m2\re
pository\jfree\jfreechart\1.0.1\jfreechart-1.0.1.jar C:\Documents and
Settings\nick\.m2\repository\commons-cli\commons-cli\1.0\commons-cli
-1.0.jar C:\Documents and Settings\nick\.m2\repository\org\safehaus\j
ug\jug\2.0.0\jug-2.0.0-asl.jar C:\Documents and Settings\nick\.m2\rep
ository\xml-apis\xml-apis\1.3.03\xml-apis-1.3.03.jar C:\Documents and
Settings\nick\.m2\repository\javax\activation\activation\1.1\activat
ion-1.1.jar C:\Documents and Settings\nick\.m2\repository\howl\howl-l
ogger\0.1.11\howl-logger-0.1.11.jar C:\Documents and Settings\nick\.m
2\repository\commons-io\commons-io\1.3.1\commons-io-1.3.1.jar C:\Docu
ments and Settings\nick\.m2\repository\jfree\jcommon\1.0.0\jcommon-1.
0.0.jar C:\Documents and Settings\nick\.m2\repository\oro\oro\2.0.7\o
ro-2.0.7.jar C:\Documents and Settings\nick\.m2\repository\xerces\xer
cesImpl\2.8.1\xercesImpl-2.8.1.jar C:\Documents and Settings\nick\.m2
\repository\org\apache\activemq\apachemq-allinone\4.1.1\apachemq-alli
none-4.1.1.jar C:\Documents and Settings\nick\.m2\repository\org\slf4
j\slf4j-log4j12\1.3.1\slf4j-log4j12-1.3.1.jar C:\Documents and Settin
gs\nick\.m2\repository\javax\mail\mail\1.4\mail-1.4.jar C:\Documents
and Settings\nick\.m2\repository\mockobjects\mockobjects-core\0.09\mo
ckobjects-core-0.09.jar C:\Documents and Settings\nick\.m2\repository
\jotm\jotm_jrmp_stubs\2.0.10\jotm_jrmp_stubs-2.0.10.jar C:\Documents
and Settings\nick\.m2\repository\org\slf4j\slf4j-api\1.3.1\slf4j-api-
1.3.1.jar C:\Documents and Settings\nick\.m2\repository\org\mule\tran
sports\mule-transport-email\1.4.1\mule-transport-email-1.4.1.jar C:\D
ocuments and Settings\nick\.m2\repository\commons-collections\commons
-collections\3.2\commons-collections-3.2.jar C:\Documents and Setting
s\nick\.m2\repository\jotm\jotm\2.0.10\jotm-2.0.10.jar C:\Documents a
nd Settings\nick\.m2\repository\org\mule\transports\mule-transport-ft
p\1.4.1\mule-transport-ftp-1.4.1.jar C:\Documents and Settings\nick\.
m2\repository\org\apache\geronimo\specs\geronimo-j2ee-connector_1.5_s
pec\1.0.1\geronimo-j2ee-connector_1.5_spec-1.0.1.jar C:\Documents and
Settings\nick\.m2\repository\commons-pool\commons-pool\1.3\commons-p
ool-1.3.jar

According to the Java Extensions spec, these paths should be RELATIVE. According to http://java.sun.com/j2se/1.5.0/docs/guide/extensions/spec.html

"""An application (or, more generally, JAR file) specifies the relative URLs of the optional packages (and libraries) that it needs via the manifest attribute Class-Path. This attribute lists the URLs to search for implementations of optional packages (or other libraries) if they cannot be found as optional packages installed on the host Java virtual machine*. These relative URLs may include JAR files and directories for any libraries or resources needed by the application or optional package. Relative URLs not ending with '/' are assumed to refer to JAR files. For example,

Class-Path: servlet.jar infobus.jar acme/beans.jar images/

Multiple Class-Path headers may be specified, and are combined sequentially.

Currently, the URLs must be relative to the code base of the JAR file for security reasons. Thus, remote optional packages will originate from the same code base as the application. A future enhancement will leverage the facilities of the Java 2 Platform's Security APIs to allow references to JAR files at other URLs. """

I googled to see if absolute paths were really an issue and It seems that a few others have encountered this before also;

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4811221

So how are you producing the jar manifest?

I'm confused by all the chatter on this bug. I just applied the patch from SUREFIRE-180 / SUREFIRE-118 which I THINK fixes this bug also (or, if that won't do it, you should be able to accomplish what you need to accomplish using the argLine parameter).

If not, please provide a reduced test case in the form of a minimal Maven project that highlights the problem.