ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From WebServices Development <WebServices_Developm...@csx.com>
Subject RE: ANT 'javac' task and 'fork' attribute
Date Fri, 01 Feb 2013 11:41:39 GMT
Sorry, just realized that from my statement below, it may appear I do not want to try figuring
it out.   I tried to add it as a compilerarg, using "value" and "line" and "cp" and "classpath"
in combinations, but it doesn't work, hence I am looking for an example.

Thank you.

-----Original Message-----
From: WebServices Development [mailto:WebServices_Development@csx.com] 
Sent: Thursday, January 31, 2013 10:54 PM
To: user@ant.apache.org
Subject: RE: ANT 'javac' task and 'fork' attribute

From the link here (http://mindprod.com/jgloss/javacmain.html ) and some other links, I thought
the class com.sun.tools.javac.Main in tools.jar is deprecated.

For your suggestion of using compilerarg attribute for classpath, can you give me an example
of how I can use it?

Thanks again.

-----Original Message-----
From: Rainer Noack [mailto:rainer@noacks.net]
Sent: Thursday, January 31, 2013 6:28 PM
To: user@ant.apache.org
Subject: Re: ANT 'javac' task and 'fork' attribute

Hi,

yep, that's the behaviour how ant works.
why do you think

com.sun.tools.javac.Main in tools.jar

is deprecated?
It's still the standard java compiler and the class that you call, when you execute the javac
application.
Yes, there is a new API (and SPI) in javax.tools but it's standard behaviour is nothing else
than just calling cst.javac.Main and i see no reason to use it in ant.
(and would require java-version dependent implementations of <javac>  as long as ant
should be backwards compatible with java 5)

However, I read your original post again and found a possible reasons why your classpath doesn't
work as expected:

<classpath path="/home/ab/antcode/RAD8ProjectsWAS7Server/StarterWeb/WebContent/WEB-INF/lib/*;/opt/local/software/websphere/v7/lib/*;/opt/local/software/websphere/v7/plugins/*"/>
is NOT the same as setting as calling javac -cp with the same path.
<classpath> (or the classpath attribute of <javac>) builds internally an Ant Path-like
structure. The Asterisk * is expanded to every file in the directory whereas the asterisk
in javac's cp is expanded to jar-files in the directory.

try the <compilerarg> element to set javac's classpath directly.

rgds

Rainer


Am 31.01.2013 20:57, schrieb WebServices Development:
> While researching when  trying to figure out why I could not use the wildcard classpath
for the javac task- even in ant 1.8.4 ( wildcards are supposed to be allowed since Ant 1.8.2
)- here is what I have inferred.   Can someone please let me know, if the inference is correct
or am I mis-guided soul here
>
> -       If you use 'fork' attribute in the 'javac' task, it uses javac of the jdk I am
running ant with ( Thanks to Rainer Noack in response to question - Which javac does ant use
in its "javac" task? )
> -       If you use 'fork' AND the 'compiler' attribute in the 'javac' task - it uses
the compiler specified by the value of the 'compiler' attribute
> -       If you do not use the 'fork' and / or 'compiler' attribute, the compile method
from com.sun.tools.javac.Main gets invoked.  This class is in tools.jar and this is a pre
jdk1.6 implementation of the compile and is also deprecated
>
>   So, my questions are
> -       Have I understood it correctly ?
> -       What would be the replacement for com.sun.tools.javac.Main
> -       How can I change the implementation to use the newer class for compile method
and use the changed implementation?  What would be the process I will need to follow?
>
>
> Thank you
>
>
>
>
>
>
> -----------------------------------------
> This email transmission and any accompanying attachments may contain 
> CSX privileged and confidential information intended only for the use 
> of the intended addressee.  Any dissemination, distribution, copying 
> or action taken in reliance on the contents of this email by anyone 
> other than the intended recipient is strictly prohibited.  If you have 
> received this email in error please immediately delete it and  notify 
> sender at the above CSX email address.  Sender and CSX accept no 
> liability for any damage caused directly or indirectly by receipt of 
> this email.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Mime
View raw message