On 3/30/07, Christopher Gardner <[EMAIL PROTECTED]> wrote:
Do you recommend I explicitly do this in my ant script:
set CLASSPATH=
Yep. ant.bat also supports a -nocp switch now (or something similar),
which is highly recommended by the Ant team (AFAIK), and certainly
myself. Just look at all th
I didn't mean to imply that I don't set the classpath in the junit
task. I definitely do that. I just don't change the environment
variable anywhere, which is what you were talking about. Do you
recommend I explicitly do this in my ant script:
set CLASSPATH=
(to null)?
On 3/30/07, Dominique
On 3/30/07, Christopher Gardner <[EMAIL PROTECTED]> wrote:
I'm having cruise run the standard ant.bat in ANT_HOME/bin, but not
explicitly resetting the CLASSPATH anywhere.
On 3/30/07, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> On 3/30/07, Christopher Gardner <[EMAIL PROTECTED]> wrote:
> > I
I'm having cruise run the standard ant.bat in ANT_HOME/bin, but not
explicitly resetting the CLASSPATH anywhere.
On 3/30/07, Dominique Devienne <[EMAIL PROTECTED]> wrote:
On 3/30/07, Christopher Gardner <[EMAIL PROTECTED]> wrote:
> I just verified that I was using the antscript option in my crui
On 3/30/07, Christopher Gardner <[EMAIL PROTECTED]> wrote:
I just verified that I was using the antscript option in my cruise
config.xml. Thanks for the idea, though.
But do you reset the CLASSPATH env. var in that script? --DD
-
I just verified that I was using the antscript option in my cruise
config.xml. Thanks for the idea, though.
Chris
On 3/30/07, Dominique Devienne <[EMAIL PROTECTED]> wrote:
On 3/30/07, Christopher Gardner <[EMAIL PROTECTED]> wrote:
> [...] The junit task doesn't override any forking or
> class
On 3/30/07, Christopher Gardner <[EMAIL PROTECTED]> wrote:
[...] The junit task doesn't override any forking or
classloading defaults.
[...] Now, if I set the junit options to be fork="true" and forkmode="once",
calling the master build.xml through the command line and eclipse
works perfectly; ca
Same code base environment (projects a, b, c, and d) described in the
prior posting "Ant 1.6.5 Classloading and JUnit Problem 1" (ant 1.6.5,
Java 1.5, Windows, eclipse 3.2.2, CruiseControl).
There is a third-party directory at the same level as the individual
project directories. Ea
I'm having a couple of ant problems that appear to be related to
classloading. The first problem may be more of a CruiseControl
question, but I'll try this group as well. I'll describe the second
problem in another posting.
In a Windows environment with Java 1.5, I have a master build.xml file
I have several ant scripts that invoke the next ant script via .
The last ant script has a task that invokes Java code.
There is a problem in the Java code that the File class cannot find the file
with a relative path.
I can resolve this by using the complete path to the file.
This problem does no
Not quite,
one can use the "classloader" task as implemented
in bugzilla 28228. http://enitsys.sourceforge.net/ant-classloadertask/
Please note that this uses
protected methods on the java classes and thus may not
be future compible.
However, I do think that optional ant tasks should not
require t
> i didn't quite catch the resolution to this. is there a
> solution to using a stock ant distribution , without
> modifying your target environment (ANT_HOME/lib, ~/.ant/lib,
> etc), and using the optional tasks such as junit, scp, ftp,
> etc? if so, can someone give an example of how to do t
i didn't quite catch the resolution to this. is there a solution to
using a stock ant distribution , without modifying your target
environment (ANT_HOME/lib, ~/.ant/lib, etc), and using the optional
tasks such as junit, scp, ftp, etc? if so, can someone give an example
of how to do this?
On 11/9
> --- Jon Skeet <[EMAIL PROTECTED]> wrote:
> [SNIP]
> > I've made the change (as well as fixing up some HTML
> > problems) and
> > mailed the file to Steve for check-in. It looks like I
> don't have SVN
> > access after all - either that, or I've got a different username or
> > password to befor
Hi Jon,
long time no see.
On Tue, 8 Nov 2005, Jon Skeet <[EMAIL PROTECTED]> wrote:
> Assuming I actually *do* still have write-access, shall I add these
> two properties to the manual in SVN?
No, you don't. This is the current list of people with write access
to Ant's svn.
ant=rubys,conor,bod
--- Jon Skeet <[EMAIL PROTECTED]> wrote:
[SNIP]
> I've made the change (as well as fixing up some HTML
> problems) and
> mailed the file to Steve for check-in. It looks like
> I don't have SVN
> access after all - either that, or I've got a
> different username or
> password to before.
>
To commi
> FYI ${ant.home} is documented on
> using.html#built-in-props
>
> ${ant.library.dir} should probably be documented alongside it
> and share its caveat.
Yup - I noticed that when I dived into SVN. (It's not in the online
manual, which is what I was looking at before.)
I've made the change (
--- Steve Loughran <[EMAIL PROTECTED]> wrote:
> Jon Skeet wrote:
> > Steve wrote:
> >
> >>${ant.home}/lib
> >>${user.home}/.ant/lib
> >
> >
> > Having just checked the source, it's even easier
> than that (for the
> > first one): ${ant.library.dir}
> >
> > Both ant.home and ant.library.dir w
Steve wrote (replying to me):
> > I think if Ant provided a property for its "home" location
> ${ant.home}/lib
> ${user.home}/.ant/lib
You star. Could I suggest that ant.home should be added to the manual?
(I did look on the website first, honest!) I suppose I could just edit
it in CVS myself
Jon Skeet wrote:
Steve wrote:
${ant.home}/lib
${user.home}/.ant/lib
Having just checked the source, it's even easier than that (for the
first one): ${ant.library.dir}
Both ant.home and ant.library.dir work from Eclipse, too, which I had
worried about a little bit...
Assuming I actually *do
Steve wrote:
> ${ant.home}/lib
> ${user.home}/.ant/lib
Having just checked the source, it's even easier than that (for the
first one): ${ant.library.dir}
Both ant.home and ant.library.dir work from Eclipse, too, which I had
worried about a little bit...
Assuming I actually *do* still have write-
Jon Skeet wrote:
This is a similar issue with the xalan classes in the 1.4 jdk.
they're exposed directly by sun (and other jvm's) as org.apache.*.
basically they just imported xalan and possibly other apache
classes into the jvm. this gives your entire application
(jvm) one chance to override
> This is a similar issue with the xalan classes in the 1.4 jdk.
> they're exposed directly by sun (and other jvm's) as org.apache.*.
> basically they just imported xalan and possibly other apache
> classes into the jvm. this gives your entire application
> (jvm) one chance to override the ver
Jon,
This is a similar issue with the xalan classes in the 1.4 jdk.
they're exposed directly by sun (and other jvm's) as org.apache.*.
basically they just imported xalan and possibly other apache classes
into the jvm. this gives your entire application (jvm) one chance to
override the version u
Currently, our build uses a modified distribution of Ant - all the
optional libraries we need are bundled into the lib directory. We use a
similarly modified version of Eclipse (i.e. the Ant part has the same
changes made).
Needless to say, this is somewhat suboptimal. I want to move to a system
w
This problem is similar to John Hohlen (1/6/2004) "Can't Run JUnits With ANT
1.6"
I check Antoine's reply, however no luck.
Here are my findings:
I am in the process of migrating build scripts from ANT 1.5.4 to 1.6. The
migration
has gone relatively smooth until, I execute a target that has JUn
Dear Han,
My suggestion is:
-- Original Message --
From : Jimmy Han([EMAIL PROTECTED])
To : [EMAIL PROTECTED]
Sent : Wednesday, Jul 16, 2003 07:59 AM
Subject : junit problem
> I know this has been asked for manu times
27 matches
Mail list logo
