Re: [Patch] trying solve w2k command line length limitations
Stefan Bodewig [EMAIL PROTECTED] escribió en el mensaje news:[EMAIL PROTECTED] On Sat, 5 Apr 2003, Ignacio J. Ortega [EMAIL PROTECTED] wrote: what i've tried is to create a properties file from gump instead of passing the classpath in the command line, make a Launcher class that loads it in a URLclassloader and start ant's main, Which also implies that we'll need to go through Ant's codebase and replace all Class.forName() calls (we better do that anyway 8-). I didnt understand this, why? the problem i've found when using the URLCL approach, is more a problem of javac that didnt use resources loaded in the CL to compile, instead it needs a real classpath with jar or classfiles in it.. or i understand you badly? i've modified ant Path type to add this property to the classpath like it's done with java.class.path ( this property is readonly ).., and if using build.sysclasspath=only, this property contents are added in addition to java.class.path.. Which introduces a hole to defeat Gump, or any other setup that uses build.sysclasspath=only. I've not looked into the patch, but we'll have to ensure that ant.class.path will be set to java.class.path when the launcher has not been used - and do that before the user had a chance to set this property. How can i signal ant that is used by Launcher instead of directly? and the porpouse of the launcher is that precisely, to launch ant with a given classpath but not passing it in the command line, so how can ant set a property before the launcher ? -- Saludos, Ignacio J.Ortega Nevada Soft
Re: [Patch] trying solve w2k command line length limitations
Stefan Bodewig [EMAIL PROTECTED] escribió en el mensaje news:[EMAIL PROTECTED] On Mon, 7 Apr 2003, Ignacio J. Ortega [EMAIL PROTECTED] wrote: Which also implies that we'll need to go through Ant's codebase and replace all Class.forName() calls (we better do that anyway 8-). I didnt understand this, why? Class.forName will use the system classloader and not the nice little IMHO This contradicts my experience of CLs, i think some places inside tomcat used Class.forName also, and never seen what you say.. Class.forName loads in the current loader and delegates to parent if needed AFAIK, but i'm little far from the code.. now.. so i can be worng.. i'm not arguing only very surprised, and trying to get to speed in the related facts.. -- Saludos, Ignacio J.Ortega Nevada Soft
Re: [Patch] trying solve w2k command line length limitations
Costin Manolache [EMAIL PROTECTED] escribió en el mensaje news:[EMAIL PROTECTED] The problem seems to be that we need a way to pass a CLASSPATH but without using the env variable. And this needs to have the override properties of the CLASSPATH that are used in gump. Well, the problem is the maximun command line length, not only the env size, if i understand you well.., later the env var is use as part of java command that launches ant from gump, and passing -D for ant in the command line has the exact same problem.. but the later is easy to overcome with a simple -propertyfile args to ant.. well to comment a bit more, the stupid cmd.exe, adds a blank space after every echo routed to a file.. so is a little more complicated.. :(.. Wouldn't be simpler to just add a bit of code to set java.class.path from a file or property ? If you go with a wrapper that embeds ant, that would be pretty simple and not need any changes to ant. I think i've tried modifying java.class.path, and ended at nowhere, i thought it was controlled to be read-only, not found any reference in JDK to the use of java.class.path, but reviewing my patch another time and given the name of the property i propose, maybe i confused java.class.path with java.classpath, so i'll try another time.. :) to see what happens.. Thanks to point this obvious issue.. :) -- Saludos, Ignacio J.Ortega Nevada Soft
[Patch] trying solve w2k command line length limitations
Hola a todos:
I'm trying to solve w2k command line length problems for gump.
what i've tried is to create a properties file from gump instead of
passing the classpath in the command line, make a Launcher class that
loads it in a URLclassloader and start ant's main, this approach by
itself doesnt work at all, javac needs real jars in a real classpath not
a CL with all the jars loaded..
Hence this patch, the Launcher in addition to create a UCL, adds a
system property ant.class.path and starts ant's Main.. i've modified ant
Path type to add this property to the classpath like it's done with
java.class.path ( this property is readonly ).., and if using
build.sysclasspath=only, this property contents are added in addition to
java.class.path..
Comments are welcomed..
Saludos,
Ignacio J. Ortega
Index: src/main/org/apache/tools/ant/types/Path.java
===
RCS file:
/home/cvspublic/ant/src/main/org/apache/tools/ant/types/Path.java,v
retrieving revision 1.47
diff -u -r1.47 Path.java
--- src/main/org/apache/tools/ant/types/Path.java 11 Mar 2003
10:57:42 - 1.47
+++ src/main/org/apache/tools/ant/types/Path.java 5 Apr 2003
16:28:25 -
@@ -103,6 +103,9 @@
public static Path systemClasspath =
new Path(null, System.getProperty(java.class.path));
+public static Path antClasspath =
+new Path(null, System.getProperty(ant.classpath));
+
/**
* Helper class, holds the nested codelt;pathelementgt;/code
values.
@@ -556,7 +559,8 @@
if (order.equals(only)) {
// only: the developer knows what (s)he is doing
result.addExisting(Path.systemClasspath, true);
-
+result.addExisting(Path.antClasspath, true);
+
} else if (order.equals(first)) {
// first: developer could use a little help
result.addExisting(Path.systemClasspath, true);
