Brett Porter wrote:
Hi Kenney,
Would be interested to get your thoughts on the issues being seen with
useSystemClassLoader and the reasoning for going with a JAR to execute
it that way. Before I can continue with the release I need to put them
to bed.
I'll have to see what the issues are, but there are some usecases for flat
classloading
apps, where surefire needs everything in the system classloader. I'm sure you
understand
the need for this feature - i've tried to convince people otherwise but finally
saw that
it was a valid usecase.
I'm using the jar solution (pretty nifty, if I say so myself ;) to circumvent
the
'commandline too long' problem on most architectures.
The problem is, that in order to have all dependencies in the system
classloader, they need to be specified
after the -classpath argument. Having a metadata file and a custom classloader
won't work here.
The commandline gets long pretty quick, so I write an empty jar with
MANIFEST.MF file containing all
the classpath elements, and then just run java -jar on that jar.
(You can even distribute that jar as a standalone testcase, as long as the artifacts are present in the local repo
and no workspace locations are used - thought that might be something we may
explore in the future).
- Brett
On 25/05/2007, at 5:01 PM, Brett Porter wrote:
I'm starting to find a number of bugs related to useSystemClassLoader,
by virtue of it being a forked JAR call. I'd be interested to get more
input on why this route was taken and how the classloading in general
works now (would be a handy document to have).
See above for the reason of this solution.
Which bugs exactly?
On 24/05/2007, at 7:39 PM, Brett Porter wrote:
Hi Kenney,
Are you able to comment on whether this is a correct solution? You
added this feature in
http://svn.apache.org/viewvc?view=rev&revision=489098
Solution to what? The stuff you merged was thorougly tested so it should be ok.
update, just checked trunk and somebody broke it. It uses urls now, which is
wrong. This is not the same
output as is on the jira issue btw.
Also, can you check whether
http://jira.codehaus.org/browse/SUREFIRE-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
should be closed as fixed as it was originally, and a new issue
created for their problems, or if it wasn't in fact fixed?
It was fixed; i asked for feedback there. No idea why it doesn't work for them.
I do however know there were issues with the surefire plugin, but haven't seen
those problems since.
I'll fix up trunk to work like it did before again, then deploy and let's see
if 2.4 works then.
-- Kenney
Thanks!
- Brett
On 24/05/2007, at 7:33 PM, [EMAIL PROTECTED] wrote:
Author: brett
Date: Thu May 24 02:33:01 2007
New Revision: 541236
URL: http://svn.apache.org/viewvc?view=rev&rev=541236
Log:
[SUREFIRE-326] make it the default to use the system classloader,
for consistency with surefire 2.2
Modified:
maven/surefire/branches/surefire-2.3.x/maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java
Modified:
maven/surefire/branches/surefire-2.3.x/maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java
URL:
http://svn.apache.org/viewvc/maven/surefire/branches/surefire-2.3.x/maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java?view=diff&rev=541236&r1=541235&r2=541236
==============================================================================
---
maven/surefire/branches/surefire-2.3.x/maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java
(original)
+++
maven/surefire/branches/surefire-2.3.x/maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java
Thu May 24 02:33:01 2007
@@ -379,7 +379,7 @@
* forking. Prevents problems with JDKs which implement the
service provider lookup mechanism by using
* the system's classloader.
*
- * @parameter expression="${surefire.useSystemClassLoader}"
default-value="false"
+ * @parameter expression="${surefire.useSystemClassLoader}"
default-value="true"
*/
private boolean useSystemClassLoader;
