I'm running Ant 1.4.1 under JDK 1.3.1. I need to
compile some projects to be run under JDK 1.1.8.
See the buld.xml below...
Ant is *NOT* properly compiling with JDK 1.1. I can
tell this two ways. During the compile, I get deprecation
warnings for things that were not deprecated until 1.2.
And
tried forking to see if that would work?
a suggestion offhand...
On Thu, 20 Jun 2002 10:42:23 Jeff Larsen wrote:
I'm running Ant 1.4.1 under JDK 1.3.1. I need to
compile some projects to be run under JDK 1.1.8.
See the buld.xml below...
Ant is *NOT* properly compiling with JDK 1.1. I
If I use fork, ant says this, and continues to compile as before.
[javac] Since fork is true, ignoring build.compiler setting.
- Original Message -
From: Ultra Funkular [EMAIL PROTECTED]
To: Ant Users List [EMAIL PROTECTED]
Sent: Thursday, June 20, 2002 11:43 AM
Subject: Re:
Are you specifying the {bootclasspath} and property as well?
You need to reference the bootclasspath and the target attribute
of javac, not just the target attribute
This is then so that the JDK1.3.1 compiler still compiles against
the JDK1.1.8 API, and compiles JDK1.1.8 classes
So for instance
Sorry, its been a hard day, let me rephrase that:
Are you specifying the {bootclasspath} and {target} attributes as well?
-Geoff
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
I have been getting the same message, since switching from 1.4.1 to 1.5, and
I do have bootclasspath set:
javac
target=1.1
fork=yes
memoryInitialSize=192m
memoryMaximumSize=256m
debug=${debug_flag}
optimize=${optimize_flag}
nowarn=off
Bingo!
Moving %JAVA_HOME%/lib/classes.zip from {classpath} to
{bootclasspath} did it. It sure would have been nice
if this were better documented! The purpose of
bootclasspath isn't really explained in the Ant 1.4.1 docs.
Thanks!
Jeff
- Original Message -
From: Geoff Meakin [EMAIL
I sent this to Bela privately, but thought maybe someone else might find
it useful. See:
http://marc.theaimsgroup.com/?l=ant-devm=102444112702134w=2
for what he was looking to do. (Nutshell: Compile from a subdir only those
files in the current directory on down.)
target name=compile
path
I have my ANT script compiling, JARing, and FTPing. Unfortunately I can't
seem to find a way to link the latter two to only if a compile occurred.
I see that FTP will only upload if the timestamps indicate a need, so if I
could only re-JAR if needed I think I'd be in good shape. Unfortunately I
I am using copy to copy some files. It is set up to use
preservelastmodified and a fileset, something like this:
copy todir=${webapp.copy_dir}
preservelastmodified=true
fileset dir=.
include name=WEB-INF/**/
include
--- Adam Jack [EMAIL PROTECTED] wrote:
I see that FTP will only upload if the timestamps indicate a need, so if
I could only re-JAR if needed I think I'd be in good shape.
That should be the default behaviour. Are you saying it recreates the jar
even if none of the files that go into it are
--- Adam Jack [EMAIL PROTECTED] wrote:
I see that FTP will only upload if the timestamps indicate a need, so if
I could only re-JAR if needed I think I'd be in good shape.
Diane wrote:
That should be the default behaviour. Are you saying it recreates the jar
Stefan Bodewig wrote:
A slightly hacked ant 1.4.1 works with Saxon instead of
Xalan+Xerces. It would be worth a try whether ant 1.5b
will work with Saxon out of the box.
What kind of hack has been involved?
Replacing SAX1 by SAX2 interfaces. IIRC:
Parser-XMLReader
DocumentHandler -
--- Adam Jack [EMAIL PROTECTED] wrote:
No, I am saying I never knew that from my reading of the documentation.
It makes sense, although it tends to contradict the documentation
section on the update attribute.
The 'update' attr specifies whether to recreate the jar, or just update an
existing
Hi
I'm using ant 1.5 beta 2 with 1.3.1 on Linux and Win2000
Here is the build snipit
target name=available depends=tdefs, properties
condition property=PCSC
available classname=com.cryptocard.jpcsc.Card
classpath location=${classes}/
/available
/condition
--- Jesse Stockall [EMAIL PROTECTED] wrote:
fail
message=com.cryptocard.jpcsc.PCSC must be compiled first
unless=${PCSC}
Whenever the name of a property is being asked for, not the value, just
use the name itself, without enclosing it in ${}. (In other words, your
fail was
--- Adam Jack [EMAIL PROTECTED] wrote:
I see that FTP will only upload if the timestamps indicate a need, so if
I could only re-JAR if needed I think I'd be in good shape.
That should be the default behaviour. Are you saying it recreates the jar
even if
Ok, so by commenting out my manifest for now I can reduce redundant JARs
and FTPs...
Any way to reduce redundant junits and/or javadocs? It seems (to me who is
no ant expert) that a property is the only way to carry context (such as
nothing newly compiled) to things like junit (and perhaps
Sadly it seems that the manifest entry is causing the rebuild
of the JAR.
According to the doc, if you have use the manifest element, it checks
whether the build file is newer than the jar -- have you tried running
your target twice in a row without any build-file diddling in-between?
Diane
E. -
Here's the build file I use. Right now, each document is separate to get
around the Xalan bug. It's not pretty, but it works.
Derek
[EMAIL PROTECTED]
http://www.mm.com/user/djdees
Sarchasm: The gulf between the author of sarcastic wit and the person who
doesn't get it.
build.xml
On Thu, 2002-06-20 at 15:30, Diane Holt wrote:
Whenever the name of a property is being asked for, not the value, just
use the name itself, without enclosing it in ${}. (In other words, your
fail was running because you don't have a property named (literally)
${PCSC} set -- you have a
Sadly it seems that the manifest entry is causing the rebuild
of the JAR.
According to the doc, if you have use the manifest element, it checks
whether the build file is newer than the jar -- have you tried running
your target twice in a row without any
--- Adam Jack [EMAIL PROTECTED] wrote:
Any way to reduce redundant junits and/or javadocs? It seems (to me who
is no ant expert) that a property is the only way to carry context
(such as nothing newly compiled) to things like junit (and perhaps
javadoc, but...) that can't really guess.
See
I logged this as bug 9713 a while back:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9713
-Original Message-
From: Diane Holt [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 20, 2002 12:51 PM
To: Ant Users List; [EMAIL PROTECTED]
Subject: Re: manifest causes jar to rebuild (was
I'm running a 1.5 alpha version of ant and I find that the dir attribute of the junit
task does not work as advertised.
The junit target in my build file starts like this
junit printsummary=yes fork=yes dir=${build.classes}
yet I find from the error messages that the vm has NOT been
--- Mark Womack [EMAIL PROTECTED] wrote:
I am using copy to copy some files.
[snip]
My problem is that after I have copied the set of files once and perform
the copy again, the copy task recopies some of the files, even though
none of the files have changed. And not all of them get recopied,
On Thursday, June 20, 2002, at 01:31 PM, Garrick Olson wrote:
I logged this as bug 9713 a while back:
Ah! That explains a lot - I thought I was getting recompiles because
zip has a rather large time granularity, but instead, it is this
manifest bug. Now that I know, I shall just put up
All you would have to do tell ANT to assume that all source files have been modified
since they were last compiled, (which probably means just disable the code that checks
the last modified timestamps on the source files). If I touch all of the source
files, ANT compiles everything exactly as
Good-God man! That's hideous!
- Original Message -
From: Geoff Meakin [EMAIL PROTECTED]
To: Ant Users List [EMAIL PROTECTED]
Sent: Thursday, June 20, 2002 4:33 AM
Subject: RE: ?? A Clean-Up Task that Always Runs ??
Here's a really ugly way to do it, assuming you want to contain
the
It's pretty tricky, the easiest way is to change the [.bat|.sh] that
runs ANT to append cleanUp after the list of supplied targets.
Trying to do the same in an ANT script is problematic as Main calls
Project.executeTargets(Vector) but the Vector of targets to call is
not available outside that
I'm having a problem with some conditionals, or in particular uptodate on
the Windows platform, hoping someone can point out the problem.
condition property=create-tables.notRequired
or
uptodate targetfile=${src}/data/create_global_tables.sql
srcfiles dir= ${src}/data/datamodel
31 matches
Mail list logo
