subject:"javac"

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39183.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39183





--- Additional Comments From [EMAIL PROTECTED]  2006-04-03 08:35 ---
Guess this ant._internal.javac.source property could work to get arround all
those broken packages. As I understand this breaking apps issue: What about
issuing a warning, if source is not set? Don't care that much about target
as it is implied by source.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39183] - Make source attribute of javac mandatory

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39183.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39183





--- Additional Comments From [EMAIL PROTECTED]  2006-04-03 15:22 ---
The source attribute is documented with this (bolded) warning:

Note that the default value depends on the JVM that is running Ant. We highly
recommend to always specify this attribute.

If users choose to ignore this warning in the documentation, I don't know that I
can see the point of noising up builds in addition.  :|  I would be -0 on such a
runtime warning.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39183] - Make source attribute of javac mandatory

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39183.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39183





--- Additional Comments From [EMAIL PROTECTED]  2006-04-03 15:34 ---
A simple presetdef or presetdef with import (if you do not want to modify
original build file) can solve this issue. All conversation about internal
secret properties is about emulating presetdef with property files. I think it
is useful - it would be externally configurable, but a solution is already
available.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39183] - Make source attribute of javac mandatory

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39183.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39183





--- Additional Comments From [EMAIL PROTECTED]  2006-04-03 21:43 ---
aah, but presetdef changes the type of teh return of
project.createTask(javac), which could toast any custom task that assumed it
was castable. 

It is presetdef problem (or feature) that can be fixed. There is no reason for
presetdef to change task implementation class, instead project.createTask()
should set default values (maybe set by external properties or presetdef).

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39183] New: - Make source attribute of javac mandatory

2006-04-02 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39183.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39183

   Summary: Make source attribute of javac mandatory
   Product: Ant
   Version: 1.6.5
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Core
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]


Everytime Sun introduces new Java keywords - let it be assert in Java 1.4 or
enum in Java 1.5 - there are zillions of Java projects stopping to compile. To
address that issue Sun was that enlightened to give javac this nice -source
command line switch. Unfortunatly it is not use that often.

It is my strong believe that the transition to new Java versions would be much
more pleasant, if maintainers of Java projects would be forced to explicitly
express the Java dialect the project targets. To start embracing this good
practice, Ant could make the source attribute of it's javac task mandatory.
Surly this will put some burden on the shoulders of few project maintainers
whoms projects to not compile anymore and who have to incooperate build.xml
patches adding this tiny switch. But in return it takes the burden from much the
larger group of users of those packages, who fiddle with the build.xml files
manually.

If you don't see this problem as an issue, just as a random maintainer of an OS
distributing prebuilt Java packages.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39183] - Make source attribute of javac mandatory

2006-04-02 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39183.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39183





--- Additional Comments From [EMAIL PROTECTED]  2006-04-02 20:47 ---
I know this is a problem with building third party libraries, and I'm not happy
with it either.

But we cannot just switch on target= and source= things without breaking so many
build files out there it wouldnt be funny.

So this leaves us two other options
1. select a fixed language version (say java1.4), which is the default unless
something else is asked for.

2. add a back door property like ant._internal.javac.source which can be set to
a source to fix those build files that dont otherwise build on java1.5

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

javac on java1.5

2006-03-23 Thread Steve Loughran




Now that Gump has switched to java1.5, its showing up some problems in 
javac.


Specifically, it appears to be defaulting to source=1.5

This breaks junit addons

http://vmgump.apache.org/gump/public/junit-addons/junit-addons/gump_work/build_junit-addons_junit-addons.html

I checked out the source in CVS; they are not saying source=1.5; they 
are not saying anything about the source version. Yet javac has switched 
to java1.5. This is breaking backwards compatibility for builds.




Also, javac shouldnt warn people about source=1.2 on every compile:

http://vmgump.apache.org/gump/public/emma/emma/gump_work/build_emma_emma.html


 Once per build should suffice. Maybe we could set an internal property 
_internal.warned.user.about.target that only triggers a warn when it 
aint set.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: javac on java1.5

2006-03-23 Thread Dominique Devienne

 Specifically, it appears to be defaulting to source=1.5
 [...]
 I checked out the source in CVS; they are not saying source=1.5; they
 are not saying anything about the source version. Yet javac has switched
 to java1.5. This is breaking backwards compatibility for builds.

It was always my understanding that javac, just like SUN's compiler,
always defaults to the current Java source level for the JDK.

Wrong assumption? The fact that the Java language evolves, making
older sources incompatible with it, is not really pointing to a BC
issue for javac IMHO.

Gump moving to 1.5 has got to have consequences, it can't be
transparent, when new keywords and classes are added to the platform
(even new classes can break the source, when it's using import foo.*).
--DD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: javac on java1.5

2006-03-23 Thread Steve Loughran


Dominique Devienne wrote:

Specifically, it appears to be defaulting to source=1.5
[...]
I checked out the source in CVS; they are not saying source=1.5; they
are not saying anything about the source version. Yet javac has switched
to java1.5. This is breaking backwards compatibility for builds.


It was always my understanding that javac, just like SUN's compiler,
always defaults to the current Java source level for the JDK.

Wrong assumption? The fact that the Java language evolves, making
older sources incompatible with it, is not really pointing to a BC
issue for javac IMHO.

Gump moving to 1.5 has got to have consequences, it can't be
transparent, when new keywords and classes are added to the platform
(even new classes can break the source, when it's using import foo.*).
--DD


Gump didnt want to move to java1.5; junit forced their hand. Now old 
code, code that built and worked happily, has broken. The usual cause is 
that enum is now reserved.


Now, when rmic's dependency logic broke moving up to 1.5, I fixed it 
by forcing the proxy generation to be downwards compatible, so 
everything behaved as on a 1.3 or 1.4 box.


Here are some options
(1) tweak javac to build at 1.4 or below unless stated.

(2) provide a back door switch to let gump control the jvm version. that 
way old code can be built under a new compiler.


#2 has appeal.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: javac on java1.5

2006-03-23 Thread Dominique Devienne

 Now, when rmic's dependency logic broke moving up to 1.5, I fixed it
 by forcing the proxy generation to be downwards compatible, so
 everything behaved as on a 1.3 or 1.4 box.

True, and was probably the right choice. But there are fewer rmic
users than javac users, so impacts less people.

 Here are some options
 (1) tweak javac to build at 1.4 or below unless stated.

I think this would be surprising, since javac would behave
differently than javac the command line app.

 (2) provide a back door switch to let gump control the jvm version. that
 way old code can be built under a new compiler.

 #2 has appeal.

Just like you, I'd rather avoid a magic property for gump, but I don't
see another solution, since I'm not fond of #1. I won't -1 #1 yet, but
I don't like it. --DD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: javac on java1.5

2006-03-23 Thread Peter Reilly

#1 would not be backwardly compatible !

I am not too sure about #2. In the ant build
file we had to deal with this issue for a while,
it may be as well to get other project 1.5 aware.
Also new projects would have to set things so
that 1.5 (and higher) would work.

Peter


On 3/23/06, Steve Loughran [EMAIL PROTECTED] wrote:

 Dominique Devienne wrote:
  Specifically, it appears to be defaulting to source=1.5
  [...]
  I checked out the source in CVS; they are not saying source=1.5; they
  are not saying anything about the source version. Yet javac has
 switched
  to java1.5. This is breaking backwards compatibility for builds.
 
  It was always my understanding that javac, just like SUN's compiler,
  always defaults to the current Java source level for the JDK.
 
  Wrong assumption? The fact that the Java language evolves, making
  older sources incompatible with it, is not really pointing to a BC
  issue for javac IMHO.
 
  Gump moving to 1.5 has got to have consequences, it can't be
  transparent, when new keywords and classes are added to the platform
  (even new classes can break the source, when it's using import foo.*).
  --DD

 Gump didnt want to move to java1.5; junit forced their hand. Now old
 code, code that built and worked happily, has broken. The usual cause is
 that enum is now reserved.

 Now, when rmic's dependency logic broke moving up to 1.5, I fixed it
 by forcing the proxy generation to be downwards compatible, so
 everything behaved as on a 1.3 or 1.4 box.

 Here are some options
 (1) tweak javac to build at 1.4 or below unless stated.

 (2) provide a back door switch to let gump control the jvm version. that
 way old code can be built under a new compiler.

 #2 has appeal.



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: javac on java1.5

2006-03-23 Thread Steve Loughran


Peter Reilly wrote:

#1 would not be backwardly compatible !

I am not too sure about #2. In the ant build
file we had to deal with this issue for a while,
it may be as well to get other project 1.5 aware.
Also new projects would have to set things so
that 1.5 (and higher) would work.



Telling people to say you must declare a java version is no big deal; 
its easily done. But there are a lot of projects out there that built 
happily, and which now dont because gump upgraded.


Furthermore, what if we can't upgrade them all? There are old projects 
out there that havent had a change for 12+ months, but which still work. 
Its only that they dont compile on java1.5.


if we the properties ant._internal._javac.source and 
ant._internal._javac.target that set the defaults for javac, then you 
can also use them on the command line to build anything 'legacy', 
without touching the build file.



-steve




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: javac on java1.5

2006-03-23 Thread Peter Reilly

Perhaps this could be in the gump definition of a project?

Peter


On 3/23/06, Steve Loughran [EMAIL PROTECTED] wrote:

 Peter Reilly wrote:
  #1 would not be backwardly compatible !
 
  I am not too sure about #2. In the ant build
  file we had to deal with this issue for a while,
  it may be as well to get other project 1.5 aware.
  Also new projects would have to set things so
  that 1.5 (and higher) would work.
 

 Telling people to say you must declare a java version is no big deal;
 its easily done. But there are a lot of projects out there that built
 happily, and which now dont because gump upgraded.

 Furthermore, what if we can't upgrade them all? There are old projects
 out there that havent had a change for 12+ months, but which still work.
 Its only that they dont compile on java1.5.

 if we the properties ant._internal._javac.source and
 ant._internal._javac.target that set the defaults for javac, then you
 can also use them on the command line to build anything 'legacy',
 without touching the build file.


 -steve




 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: javac on java1.5

2006-03-23 Thread Dominique Devienne

 if we the properties ant._internal._javac.source and
 ant._internal._javac.target that set the defaults for javac, then you
 can also use them on the command line to build anything 'legacy',
 without touching the build file.

Even though someone could abuse these Magic properties for other
purposes, I'd prefer something like ant.gump.javac.{source|target} or
something dramatic like ant.override-attributes.javac.{source|target}.
--DD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: javac on java1.5

2006-03-23 Thread Stefan Bodewig

On Thu, 23 Mar 2006, Steve Loughran [EMAIL PROTECTED] wrote:
 Now that Gump has switched to java1.5, its showing up some problems
 in javac.
 
 Specifically, it appears to be defaulting to source=1.5

Please take the time and look into the manual page of the task, in
particular the bold-face notes on the target and source attributes ;-)

 This is breaking backwards compatibility for builds.

Quite the opposite.  Changing javac's behaviour to default to 1.3 or
something would have broken working builds on Java 1.5 when we started
to work on 1.5 support for 1.6(.2 or something).

 Also, javac shouldnt warn people about source=1.2 on every
 compile:
 
   Once per build should suffice.

+1

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: javac on java1.5

2006-03-23 Thread Stefan Bodewig

On Thu, 23 Mar 2006, Steve Loughran [EMAIL PROTECTED] wrote:

 Gump didnt want to move to java1.5;

Well, Gump being what it is should be running Mustang beta by now.
Not running 1.5 was mainly influenced by not havong one installed on
vmgump and people not having time to install it.

 junit forced their hand.

It finally pushed me to start a one hour upload of the Linux JDK
instead of playing with my kids on a weekend ;-)

 Here are some options
 (1) tweak javac to build at 1.4 or below unless stated.

-1, too late.

 (2) provide a back door switch to let gump control the jvm
 version. that way old code can be built under a new compiler.

+0

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 28142] - No attribute for -X option with javac compiler

2006-01-23 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28142.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28142





--- Additional Comments From [EMAIL PROTECTED]  2006-01-23 10:26 ---
(In reply to comment #3)
 (In reply to comment #2)
  the compilerarg element in a javac task has no effect. see below.
  I cannot run the command line because arg list is too long.
  Thanks.
 
 What exactly makes you say the arg list is too long?
 

if I run javac */*/*.java, it says arg list is too long, but this is a system
problem, not an ant problem. 
In fact, it hasn't no effect, but it sends the help stack (as if javac doesn't
understand the option) - see the next message - Thks

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 28142] - No attribute for -X option with javac compiler

2006-01-23 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28142.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28142





--- Additional Comments From [EMAIL PROTECTED]  2006-01-23 10:36 ---
(In reply to comment #4)
 Should it be compilerarg line=-Xmaxerrs 1000/ ? value attribute is for a
 single argument, but you are passing two arguments together. Another 
 possibility
 is to put two compilerarg value=.../ elements, but it is important only if
 you have spaces in the arguments.

Yep, it seems to be a problem of blanks, because if I put the -Xswitchcheck it
runs well.So, I put the args on two lines now :
 compilerarg value=-Xmaxerrs/
 compilerarg value=1000/

And it works !!! (a bit strange however) - Thanks to all.
I let you guys change the status of the bug.



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 28142] - No attribute for -X option with javac compiler

2006-01-23 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28142.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28142


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2006-01-23 10:56 ---
marking as invalid arg value params are single arguments. Ant does not build
up a command line string to send to the shell, it builds up an array of
arguments to hand off to exec. Even if there is spaces or quotes in a value, it
is still one argument. 

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 28142] - No attribute for -X option with javac compiler

2006-01-20 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28142.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28142





--- Additional Comments From [EMAIL PROTECTED]  2006-01-20 15:04 ---
(In reply to comment #2)
 the compilerarg element in a javac task has no effect. see below.
 I cannot run the command line because arg list is too long.
 Thanks.

What exactly makes you say the arg list is too long?


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 28142] - No attribute for -X option with javac compiler

2006-01-20 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28142.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28142





--- Additional Comments From [EMAIL PROTECTED]  2006-01-20 18:30 ---
Should it be compilerarg line=-Xmaxerrs 1000/ ? value attribute is for a
single argument, but you are passing two arguments together. Another possibility
is to put two compilerarg value=.../ elements, but it is important only if
you have spaces in the arguments.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38094] - allow to specify also -Xlint:unchecked for target javac

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38094.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38094





--- Additional Comments From [EMAIL PROTECTED]  2006-01-03 15:22 ---
Can't you use compilerarg for the javac task?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38094] - allow to specify also -Xlint:unchecked for target javac

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38094.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38094


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME




--- Additional Comments From [EMAIL PROTECTED]  2006-01-03 15:53 ---
You are right, I overlooked compilerarg in
http://ant.apache.org/manual/CoreTasks/javac.html - sorry.

perhaps, it might be good to add an example to the manual.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38109] New: - The regular expression is expanded on the windows in the javac task

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38109.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38109

   Summary: The regular expression is expanded on the windows in the
javac task
   Product: Ant
   Version: unspecified
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P3
 Component: Core tasks
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]


While passing regexp as an arguments to the java task on the Windows the quoted
reqular expression is expanded. It is hard to pass the regular expression to the
java application. It works fine on Linux.

java classname=test.Main dir=C:\ fork=true
arg line=${application.args}/
classpath
 
/classpath
/java

where application.args is '\d*' Foo
On th Windows the \d* is expanded into the folders on the C: drive.

Ant debug output:

Executing 'C:\jdk1.5.0\jre\bin\java.exe' with arguments:
'-classpath'
'C:\temp\JavaApplication5\build\classes'
'javaapplication5.Main'
'\d*'
'Foo'

The ' chars were removed by the CommandLine.translateCommandLine () method and
then expanded by Windows. If I pass the regexp argument as arg value='\d*'/,
the ' characters are not removed and it works fine.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38109] - The regular expression is expanded on the windows in the javac task

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38109.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38109


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2006-01-03 20:43 ---
From http://ant.apache.org/manual/using.html#arg :

It is highly recommended to avoid the line version when possible. Ant will try
to split the command line in a way similar to what a (Unix) shell would do, but
may create something that is very different from what you expect under some
circumstances.

So you've already found the solution yourself.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38094] New: - allow to specify also -Xlint:unchecked for target javac

2006-01-02 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38094.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38094

   Summary: allow to specify also -Xlint:unchecked for target
javac
   Product: Ant
   Version: 1.7Alpha (nightly)
  Platform: Other
OS/Version: Windows XP
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Core tasks
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]


When doing 
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jasper-howto.html#Web%20Application%20Compilation,
I get
[javac] Note: C:\Documents and Settings\you\My
Documents\myProj\build\jspC\org\apache\jsp\
build\jsp\samplePAge_005fen_jsp.java uses unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.

probably, this would require an additional attribute

(happens also for source=1.5 and verbose=true doesn't provide additional
 insights)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38094] - allow to specify also -Xlint:unchecked for target javac

2006-01-02 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38094.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38094





--- Additional Comments From [EMAIL PROTECTED]  2006-01-02 14:45 ---
To address the underlying jasper issue, see RFE Bug 38095

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 37148] - javac nested src element troube with excludes

2005-12-28 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37148.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37148





--- Additional Comments From [EMAIL PROTECTED]  2005-12-28 16:45 ---
Same for me,

javac 
excludes=
 src path=${src}/
 src 

just ignores the excludes part.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 37632] - javac needs to be resource aware

2005-11-28 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37632.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37632





--- Additional Comments From [EMAIL PROTECTED]  2005-11-28 16:01 ---
right... src is a path.  So, being that most javac implementations will only
know how to compile files, and path is a filesystem-only resource collection,
any type of resource collection should fit at javacsrc!-- insert any RC
here --/src/javac, as long as it does not contain any non-filesystem
resources.  That was an advantage of making path an RC.  Any task using paths
is automatically RC-enabled.  But since we like and respect you so much Steve I
will leave this open until you agree it is resolved.  ;)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 37632] New: - javac needs to be resource aware

2005-11-24 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37632.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37632

   Summary: javac needs to be resource aware
   Product: Ant
   Version: 1.7Alpha (nightly)
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Core tasks
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]


Currently, javac only takes paths and the single implicit fileset

So there is no easy way to hand it a reference to a fileset, or two filesets,
each with selectors. this needs fixing.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 37632] - javac needs to be resource aware

2005-11-24 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37632.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37632


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |NEEDINFO




--- Additional Comments From [EMAIL PROTECTED]  2005-11-24 17:10 ---
javac...
src
fileset refid=../
fileset refid=../
/src
/javac

Is that ok?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 37546] - javac compilerarg doesn't support 'modern' compiler

2005-11-20 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37546.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37546


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |1.7




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 37546] - javac compilerarg doesn't support 'modern' compiler

2005-11-18 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37546.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37546


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||dev@ant.apache.org




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 37546] New: - javac compilerarg doesn't support 'modern' compiler

2005-11-17 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37546.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37546

   Summary: javac compilerarg doesn't support 'modern' compiler
   Product: Ant
   Version: 1.6.5
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Core tasks
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]


Hi,

I'm having problems with the compilerarg element in combination with 
the 'modern' compiler.

I have this added to my javac element:
javac ...
compilerarg line=-nowarn compiler=modern /
/javac

If I run this in verbose mode, I get this on the console (using JDK1.4)

[javac] Using modern compiler
[javac] Compilation arguments:
[javac] '-d'
[javac] 'C:\test\build\classes'
[javac] '-classpath'
[javac] '...'
[javac] '-sourcepath'
[javac] 'C:\test\src'
[javac] '-g'
[javac]
[javac] The ' characters around the executable and arguments are
[javac] not part of the command.

As you can see, the '-nowarn' option is lost!

However, if I change the 'modern' compiler to 'javac1.4', it works:
javac ...
compilerarg line=-nowarn compiler=javac1.4 /
/javac

[javac] Using modern compiler
[javac] Compilation arguments:
[javac] '-d'
[javac] 'C:\test\build\classes'
[javac] '-classpath'
[javac] '...'
[javac] '-sourcepath'
[javac] 'C:\test\src'
[javac] '-g'
[javac] '-nowarn'
[javac]
[javac] The ' characters around the executable and arguments are
[javac] not part of the command.

Can you please fix this?

regards,
Maarten

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 37546] - javac compilerarg doesn't support 'modern' compiler

2005-11-17 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37546.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37546


[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|dev@ant.apache.org  |[EMAIL PROTECTED]




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34638] - javac using GCJ compiler ignores includeJavaRuntime attribute

2005-11-12 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34638.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34638





--- Additional Comments From [EMAIL PROTECTED]  2005-11-12 16:27 ---
I have some more info on this. It seems the problem stems from
org.apache.tools.ant.types.Path.addExtdirs(Path extdirs). It tests whether null
is being passed and if so then adds then value of the system property
'java.ext.dirs' (which includes the Java Runtime path!)

Adding the attribute extdirs=/home/ZZ in the same manner as the previous
work-around solves the problem.



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34638] - javac using GCJ compiler ignores includeJavaRuntime attribute

2005-11-12 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34638.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34638





--- Additional Comments From [EMAIL PROTECTED]  2005-11-12 16:59 ---
We have just discovered that includeAntRuntime=no must also be included for
this to work. I havn't investigated the reasons for this any further.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 31106] - VMS cannot handle long command strings, java, javac needs to use -v option..

2005-10-24 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31106.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31106





--- Additional Comments From [EMAIL PROTECTED]  2005-10-24 19:19 ---
(In reply to comment #26)
 Could you please confirm the issue is solved on the preliminary 1.7 version? 
(Or
 indicate that the issue has not been solved.


This issue appears to be solved in 1.7 by the patches we contributed.

At the time of the patch, I opened another issue
http://issues.apache.org/bugzilla/show_bug.cgi?id=31589

to detail the results of running the 1.7 junit tests on OpenVMS.

Please close this report.

Thanks!
 


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 31106] - VMS cannot handle long command strings, java, javac needs to use -v option..

2005-10-24 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31106.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31106


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 37174] New: - javac task and the -Xlint compiler switch

2005-10-19 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37174.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37174

   Summary: javac task and the -Xlint compiler switch
   Product: Ant
   Version: 1.6.2
  Platform: Other
OS/Version: Solaris
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Core tasks
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]


The javac task give me this following output:

Note: Some input files use unchecked or unsafe operations.Note: Recompile with
-Xlint:unchecked for details.

The javac task doesn't provide a property to enable the -Xlint compiler switch.
 I think It would be nice to have one.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 37174] - javac task and the -Xlint compiler switch

2005-10-19 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37174.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37174





--- Additional Comments From [EMAIL PROTECTED]  2005-10-19 23:36 ---
Can't you use compilerarg?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 37174] - javac task and the -Xlint compiler switch

2005-10-19 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37174.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37174


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Platform|Other   |Sun
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-10-20 04:06 ---
Yes it worked.

I was just rushing through the documentation.  Sorry.

May be you should add an example in the documentation like:
compilerarg value=-Xlint/

I'm just sorry that such a usefull option is not brought to light by having a
standard javac property assigned to it.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 37148] New: - javac nested src element troube with excludes

2005-10-18 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37148.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37148

   Summary: javac nested src element troube with excludes
   Product: Ant
   Version: 1.6.5
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Core tasks
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]


An excludes attribute in a javac call will work properly.  But when that
excludes is moved into a nested src element, the includes fails in a strange 
way.
Examples:

==
WORKING Version with attribute excludes
==
Ant project file snippet

...
  target name=game depends=init description=Builds the Game development
version
  mkdir dir=${testbuild}/
  mkdir dir=${build}/
  javac destdir=${build} deprecation=on debug=${debug}
optimize=${optimize} source=1.4 target=1.4
  excludes=poi/**/*
 srcpathelement location=src/ /src
 srcpathelement location=generated/ /src
 classpath refid=project.class.path/
  /javac
   /target
...
===
ant output snippet
===

fileset: Setup scanner in dir /home/cafgdev/CAFG/src with patternSet{ includes:
[] excludes: [poi/**/*] }[javac]
com/gametable/games/cafg/client/AbilityEditor.java omitted as
com/gametable/games/cafg/client/AbilityEditor.class is up to date.
[javac] com/gametable/games/cafg/client/AttackEditor.java omitted as
com/gametable/games/cafg/client/AttackEditor.class is up to date.

...
fileset: Setup scanner in dir /home/cafgdev/CAFG/generated with patternSet{
includes: [] excludes: [poi/**/*] }
...
==
=
FAILS
=
project file snippet

...
  target name=game depends=init description=Builds the Game development
version
  mkdir dir=${testbuild}/
  mkdir dir=${build}/
  javac destdir=${build} deprecation=on debug=${debug}
optimize=${optimize} source=1.4 target=1.4
 srcfileset dir=src excludes=poi/**/*//src
 srcpathelement location=src/ /src
 srcpathelement location=generated/ /src
 classpath refid=project.class.path/
  /javac
   /target
...
==
ant output  (note the repeated fileset output below
  which does not occur in the successful compile)
==
...
fileset: Setup scanner in dir /home/cafgdev/CAFG/src with patternSet{ includes:
[] excludes: [poi/**/*] }fileset: Setup scanner in dir /home/cafgdev/CAFG/src
with patternSet{ includes: [] excludes: [poi/**/*] }
BUILD FAILED
/home/cafgdev/CAFG/build.xml:47:
/home/cafgdev/CAFG/src/com/gametable/games/cafg/client/AbilityEditor.java is not
a directory.
at
org.apache.tools.ant.types.AbstractFileSet.getDirectoryScanner(AbstractFileSet.java:352)
at
org.apache.tools.ant.taskdefs.MatchingTask.getDirectoryScanner(MatchingTask.java:186)
at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:751)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at org.apache.tools.ant.Target.performTasks(Target.java:369)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
at org.apache.tools.ant.Project.executeTargets(Project.java:1068)
at org.apache.tools.ant.Main.runBuild(Main.java:668)
at org.apache.tools.ant.Main.startAnt(Main.java:187)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)

=

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 36939] - javac having issues compiling few classes

2005-10-06 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36939.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36939


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-10-06 10:36 ---
This is not an ant issue.
issue 1: character encoding
Javac in java 1.5 is much more strict with regard to
the characters in java source files. By default on unix/linux
the character encoding is utf-8. With utf-8 characters outside the 127 range
have different encoding - and some byte sequences are not allowed.
It looks like you are encodeing using iso 8857-1 (latin1) and not utf-8 -
hence the warning messages. Your options are a) change the encoding to utf-8
b) tell javac to use the iso 8857 encodeing by useing the encoding attribute (I 
do
not know the value) or c) convert the characters to us-ascii (i.e. under 127)
issue 2: classpath
Javac in java 1.5 is much more strict with regard to the contents of the
classpath.
If you do javac -classpath AdvancedTimer.java *.java
where AdvancedTimer.java exists and is not a jar file, you will get an
error in java 1.5 but not in java 1.4.
With ant, it is easy to construct these invalid classpaths.
for example
target name=bad
   javac srcdir=src
   classpath
  fileset dir=src/
   /classpath
   /javac
/target
will fail giving the error:
bad:
Compiling 1 source file
error: error reading /home/preilly/learning/a/1.5/src/Test.java; error in
opening zip file
1 error


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 36939] - javac having issues compiling few classes

2005-10-06 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36939.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36939


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED




--- Additional Comments From [EMAIL PROTECTED]  2005-10-06 20:14 ---
It seems it is an issue with ANT itself, or atleast how it views classpath.
Rather I would say it is a java 1.5 feature (issue I would call it).

I created a jar for the *.java, and then included that in the classpath.



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 36939] New: - javac having issues compiling few classes

2005-10-05 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36939.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36939

   Summary: javac having issues compiling few classes
   Product: Ant
   Version: 1.6.2
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Core tasks
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]


I am trying to compile my code, which works fine on JAVA 1.4 with ANT 1.6.2, 
but using JAVA 1.5, I get an error, which I dont understand.

This is urgent and would appreciate some help.

[javac] /usr/local/ant/Bears/tempcodeMiletus/webApi/src/de/mud/telnet/ScriptHand
ler.java:30: warning: unmappable character for encoding UTF8
[javac] * @author Matthias L. Jugel, Marcus Meiï¿½ner
[javac] ^
[javac] /usr/local/ant/Bears/tempcodeMiletus/webApi/src/de/mud/telnet/TelnetProt
ocolHandler.java:29: warning: unmappable character for encoding UTF8
[javac] * BMaintainer:/B Marcus Meiï¿½ner
[javac] ^
[javac] /usr/local/ant/Bears/tempcodeMiletus/webApi/src/de/mud/telnet/TelnetProt
ocolHandler.java:32: warning: unmappable character for encoding UTF8
[javac] * @author Matthias L. Jugel, Marcus Meiï¿½ner
[javac] ^
[javac] /usr/local/ant/Bears/tempcodeMiletus/webApi/src/de/mud/telnet/TelnetWrap
per.java:53: warning: unmappable character for encoding UTF8
[javac] * @author Matthias L. Jugel, Marcus Meiï¿½ner
[javac] ^
[javac] error: error 
reading /usr/local/ant/Bears/tempcode/webApi/src/com/dnsalias/java/timer/Advance
dTimer.java; java.util.zip.ZipException: error in opening zip file
[javac] Note: * uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint eprecation for details.
[javac] 1 error
[javac] 4 warnings

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 36939] - javac having issues compiling few classes

2005-10-05 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36939.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36939





--- Additional Comments From [EMAIL PROTECTED]  2005-10-05 20:02 ---
It works correctly when I generate the build using JAVA_HOME pointing to Java 
1.4.2_03 and _08. 



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34638] - javac using GCJ compiler ignores includeJavaRuntime attribute

2005-09-28 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34638.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34638


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |
Version|1.6.2   |1.6.5




--- Additional Comments From [EMAIL PROTECTED]  2005-09-28 22:19 ---
This seems to have crept back in 1.6.5.

Worse yet, the described work around does not work either.

This for gcj compiler.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34638] - javac using GCJ compiler ignores includeJavaRuntime attribute

2005-09-28 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34638.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34638





--- Additional Comments From [EMAIL PROTECTED]  2005-09-28 22:25 ---
To test this, I create a shell script named gcj in the current directory.

!/bin/sh
echo $0 $@

---
then run ant as follows:

$ PATH=.:$PATH ant

and you will see the exact command line for all of gcj

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

ant can't find javac compiler

2005-09-22 Thread paul

Dear dev@ant.apache.org, 

I am using ant to compile my struts webapp. I am using Linux 2.4.27 and 
running ant (1.5.2-26) from my shell which is bash. My environment variables 
which I set in my .bash_profile are:

$JAVA_HOME=/usr/java/jdk1.5.0_02
$CLASSPATH=/usr/java/jdk1.5.0_02/lib:/usr/java/jdk1.5.0_02/jre/lib 

Here is my problem. When I compile my classes using the default compiler for 
my system (kjc) I get this error: 

error: Can't find default package `java.lang'. Check the CLASSPATH 
environment variable and the access to the archives 

Which I can live with (even though my CLASSPATH variable is probably 
correct) since I really ought to be using the jdk1.5.0_02 compiler. If I set 
the compiler attribute of javac task in my build.xml to modern, it should 
use the javac compiler that comes with my JDK. When I do I get this error: 


Unable to find a javac compiler;
com.sun.tools.javac.Main is not on the classpath.
Perhaps JAVA_HOME does not point to the JDK 

If I run the javac command manually from the command prompt, something like 
this:
javac -cp MY/VERY/LONG/CLASSPATH/ src/uk/co/webotech/myproject/MyClass.java 

It compiles fine... By the way, typing which javac in my shell returns 
/usr/java/jdk1.5.0_02/bin/javac. How can I get ant to find javac? 

Any help with this would be greatly appreciated! 

Paul 



--
Paul Mackinlay (PhD, MEng)
http://www.webotech.co.uk/
[EMAIL PROTECTED]
Tel: +44(0)7050 699971
Fax: +44(0)7050 699972

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant can't find javac compiler

2005-09-22 Thread paul

Martin, 

I tried changing my $PATH as you suggested but that didn't help. Also, java 
and javac are both the same version (1.5.0_02). 

I wonder if ant runs it's processes in another shell - one perhaps that 
doesn't pick up my personal env variables? Maybe it doesn't even run them in 
bash? Could it be that ant tasks are run by a different Linux user which 
needs to be set up? 

I'm thinking out loud... if that is possible by email! 

Paul 



Martin Gainty writes: 


Paul-
2 things that I would look for 

move $JAVA_HOME\bin to front of $PATH 


make sure your JRE and JDK(SDK) are the same version
e.g.
javac -version Test.java
java -version
SHOULD report the same version 

Anyone else ??? 


Martin Gainty
(mobile) 617-852-7822
(http)www.laconiadatasystems.com 



Dear dev@ant.apache.org, 

I am using ant to compile my struts webapp. I am using Linux 2.4.27 and 
running ant (1.5.2-26) from my shell which is bash. My environment 
variables which I set in my .bash_profile are:

$JAVA_HOME=/usr/java/jdk1.5.0_02
$CLASSPATH=/usr/java/jdk1.5.0_02/lib:/usr/java/jdk1.5.0_02/jre/lib 

Here is my problem. When I compile my classes using the default compiler 
for my system (kjc) I get this error: 

error: Can't find default package `java.lang'. Check the CLASSPATH 
environment variable and the access to the archives 

Which I can live with (even though my CLASSPATH variable is probably 
correct) since I really ought to be using the jdk1.5.0_02 compiler. If I 
set the compiler attribute of javac task in my build.xml to modern, it 
should use the javac compiler that comes with my JDK. When I do I get 
this error: 


Unable to find a javac compiler;
com.sun.tools.javac.Main is not on the classpath.
Perhaps JAVA_HOME does not point to the JDK 

If I run the javac command manually from the command prompt, something 
like this:
javac -cp MY/VERY/LONG/CLASSPATH/ 
src/uk/co/webotech/myproject/MyClass.java 

It compiles fine... By the way, typing which javac in my shell returns 
/usr/java/jdk1.5.0_02/bin/javac. How can I get ant to find javac? 

Any help with this would be greatly appreciated! 

Paul 



--
Paul Mackinlay (PhD, MEng)
http://www.webotech.co.uk/
[EMAIL PROTECTED]
Tel: +44(0)7050 699971
Fax: +44(0)7050 699972 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED] 

 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED] 





--
Paul Mackinlay (PhD, MEng)
http://www.webotech.co.uk/
[EMAIL PROTECTED]
Tel: +44(0)7050 699971
Fax: +44(0)7050 699972 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant can't find javac compiler

2005-09-22 Thread Steve Loughran


[EMAIL PROTECTED] wrote:

Martin,
I tried changing my $PATH as you suggested but that didn't help. Also, 
java and javac are both the same version (1.5.0_02).
I wonder if ant runs it's processes in another shell - one perhaps that 
doesn't pick up my personal env variables? Maybe it doesn't even run 
them in bash? Could it be that ant tasks are run by a different Linux 
user which needs to be set up?

I'm thinking out loud... if that is possible by email!
Paul


0. this is more user space, not developer space questions. please send 
follow messages to that mailing list.


1. I think you should run ant -diagnostics to see what Ant's view of the 
world is


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant can't find javac compiler

2005-09-22 Thread Martin Gainty


Good Afternoon Paul
The documentation for the ant javac task is available at
http://ant.apache.org/manual/CoreTasks/javac.html
2 things..
set fork = yes
take a look at the parameter called executable
Complete path to the javac executable to use in case of fork=yes
HTH,
Martin-
- Original Message - 
From: [EMAIL PROTECTED]

To: Ant Developers List dev@ant.apache.org
Sent: Thursday, September 22, 2005 10:27 AM
Subject: Re: ant can't find javac compiler



Martin,
I tried changing my $PATH as you suggested but that didn't help. Also, 
java and javac are both the same version (1.5.0_02).
I wonder if ant runs it's processes in another shell - one perhaps that 
doesn't pick up my personal env variables? Maybe it doesn't even run them 
in bash? Could it be that ant tasks are run by a different Linux user 
which needs to be set up?

I'm thinking out loud... if that is possible by email!
Paul

Martin Gainty writes:

Paul-
2 things that I would look for move $JAVA_HOME\bin to front of $PATH 
make sure your JRE and JDK(SDK) are the same version

e.g.
javac -version Test.java
java -version
SHOULD report the same version Anyone else ??? Martin Gainty
(mobile) 617-852-7822
(http)www.laconiadatasystems.com


Dear dev@ant.apache.org, I am using ant to compile my struts webapp. I 
am using Linux 2.4.27 and running ant (1.5.2-26) from my shell which is 
bash. My environment variables which I set in my .bash_profile are:

$JAVA_HOME=/usr/java/jdk1.5.0_02
$CLASSPATH=/usr/java/jdk1.5.0_02/lib:/usr/java/jdk1.5.0_02/jre/lib Here 
is my problem. When I compile my classes using the default compiler for 
my system (kjc) I get this error: error: Can't find default package 
`java.lang'. Check the CLASSPATH environment variable and the access to 
the archives Which I can live with (even though my CLASSPATH variable is 
probably correct) since I really ought to be using the jdk1.5.0_02 
compiler. If I set the compiler attribute of javac task in my 
build.xml to modern, it should use the javac compiler that comes with my 
JDK. When I do I get this error: Unable to find a javac compiler;

com.sun.tools.javac.Main is not on the classpath.
Perhaps JAVA_HOME does not point to the JDK If I run the javac command 
manually from the command prompt, something like this:
javac -cp MY/VERY/LONG/CLASSPATH/ 
src/uk/co/webotech/myproject/MyClass.java It compiles fine... By the 
way, typing which javac in my shell returns 
/usr/java/jdk1.5.0_02/bin/javac. How can I get ant to find javac? Any 
help with this would be greatly appreciated! Paul --

Paul Mackinlay (PhD, MEng)
http://www.webotech.co.uk/
[EMAIL PROTECTED]
Tel: +44(0)7050 699971
Fax: +44(0)7050 
699972 -

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

 -
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
Paul Mackinlay (PhD, MEng)
http://www.webotech.co.uk/
[EMAIL PROTECTED]
Tel: +44(0)7050 699971
Fax: +44(0)7050 699972

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

corrupt jar files and javac

2005-09-16 Thread Steve Loughran



I would guess from this trace that there is a bad JAR file somewhere in 
my (long, convoluted, m2-tasks created) classpath, something breaking javac.


the problem of course is that javac isnt helpful enough to tell me which 
file. I have tried unzipping everything, but of course, ant's unzip 
task doesnt complain at all, and nor, apparently, does jar and exec 
executable=jar /.


what else do I have to track this down?

compile:
   [depend] The class 
org.smartfrog.services.deployapi.transport.config.Axis2ServiceImpl_Stub 
in file 
/home/slo/Projects/SmartFrog/Forge/core/components/deployapi/build/classes/org/smartfrog/services/deployapi/transport/config/Axis2ServiceImpl_Stub.class 
is out of date due to 
org.smartfrog.services.deployapi.transport.config.Axis2Service but has 
not been deleted because its source file could not be determined
[core:javac] Compiling 13 source files to 
/home/slo/Projects/SmartFrog/Forge/core/components/deployapi/build/classes

[core:javac] java.lang.IndexOutOfBoundsException
[core:javac] 	at 
java.util.zip.InflaterInputStream.read(InflaterInputStream.java:122)
[core:javac] 	at 
com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:1562)
[core:javac] 	at 
com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1518)

[core:javac]at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355)
[core:javac] 	at 
com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:614)
[core:javac] 	at 
com.sun.tools.javac.jvm.ClassReader.loadClass(ClassReader.java:1612)
[core:javac] 	at 
com.sun.tools.javac.comp.Resolve.loadClass(Resolve.java:794)
[core:javac] 	at 
com.sun.tools.javac.comp.Resolve.findIdentInPackage(Resolve.java:963)

[core:javac]at com.sun.tools.javac.comp.Attr.selectSym(Attr.java:1726)
[core:javac]at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:1649)
[core:javac]at com.sun.tools.javac.tree.Tree$Select.accept(Tree.java:993)
[core:javac]at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:256)
[core:javac]at com.sun.tools.javac.comp.Attr.attribType(Attr.java:284)
[core:javac] 	at 
com.sun.tools.javac.comp.MemberEnter.attribImportType(MemberEnter.java:655)
[core:javac] 	at 
com.sun.tools.javac.comp.MemberEnter.visitImport(MemberEnter.java:539)

[core:javac]at com.sun.tools.javac.tree.Tree$Import.accept(Tree.java:401)
[core:javac] 	at 
com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:383)
[core:javac] 	at 
com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:395)
[core:javac] 	at 
com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:506)
[core:javac] 	at 
com.sun.tools.javac.tree.Tree$TopLevel.accept(Tree.java:386)
[core:javac] 	at 
com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:383)
[core:javac] 	at 
com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:777)

[core:javac]at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355)
[core:javac] 	at 
com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:614)

[core:javac]at com.sun.tools.javac.comp.Enter.complete(Enter.java:448)
[core:javac]at com.sun.tools.javac.comp.Enter.main(Enter.java:426)
[core:javac] 	at 
com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:382)

[core:javac]at com.sun.tools.javac.main.Main.compile(Main.java:592)
[core:javac]at com.sun.tools.javac.main.Main.compile(Main.java:544)
[core:javac]at com.sun.tools.javac.Main.compile(Main.java:58)
[core:javac]at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[core:javac] 	at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[core:javac] 	at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

[core:javac]at java.lang.reflect.Method.invoke(Method.java:585)
[core:javac] 	at 
org.apache.tools.ant.taskdefs.compilers.Javac13.execute(Javac13.java:55)

[core:javac]at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:931)
[core:javac]at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:757)
[core:javac] 	at 
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: corrupt jar files and javac

2005-09-16 Thread Steve Loughran


Steve Loughran wrote:


I would guess from this trace that there is a bad JAR file somewhere in 
my (long, convoluted, m2-tasks created) classpath, something breaking 
javac.


the problem of course is that javac isnt helpful enough to tell me which 
file. I have tried unzipping everything, but of course, ant's unzip 
task doesnt complain at all, and nor, apparently, does jar and exec 
executable=jar /.


what else do I have to track this down?

compile:
   [depend] The class 
org.smartfrog.services.deployapi.transport.config.Axis2ServiceImpl_Stub 
in file 
/home/slo/Projects/SmartFrog/Forge/core/components/deployapi/build/classes/org/smartfrog/services/deployapi/transport/config/Axis2ServiceImpl_Stub.class 
is out of date due to 
org.smartfrog.services.deployapi.transport.config.Axis2Service but has 
not been deleted because its source file could not be determined
[core:javac] Compiling 13 source files to 
/home/slo/Projects/SmartFrog/Forge/core/components/deployapi/build/classes

[core:javac] java.lang.IndexOutOfBoundsException
[core:javac] at 
java.util.zip.InflaterInputStream.read(InflaterInputStream.java:122)
[core:javac] at 


The corruption is caused by duplicate .class files in the JAR. 
Fortunately it was one of my projects, and by changing the presetdef for 
jar to default=preserve and rebulding it went away. If the defect was 
in a JAR file that I was autoloading from the network repositories, I 
would have been stuffed.


Why dont we set default=preserve rather than default=add on the zip 
tasks, on the basis that it may break BC, but it is probably a bug to 
have this problem anyway?


-steve

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 36688] New: - Using var expansion in include tags fails in javac

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36688.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36688

   Summary: Using var expansion in include tags fails in javac
   Product: Ant
   Version: 1.6.5
  Platform: All
OS/Version: Windows 2000
Status: NEW
  Severity: normal
  Priority: P2
 Component: Core tasks
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]


I'm using the VAR task from Ant-Contrib.  When using a var value in the
include tags of a javac task, the expansion happens too late in the process
for javac to correctly align dependencies.

Example, You have the following structure:

/java/d1/class1.java
/java/d1/class2.java
/java/d2/class3.java

Class1 depends on class3, which depends on class2.

You can correctly compile this scenerio with this code:

javac srcdir=/java
  include name=d1/*.java /
  include name=d2/*.java /
/javac

However, the following code fails.

var name=D1 value=d1 /
var name=D2 value=d2 /
javac srcdir=/java
  include name=${D1}/*.java /
  include name=${D2}/*.java /
/javac

You will get in error in javac stating that the dependency that class3 could not
be found.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 36688] - Using var expansion in include tags fails in javac

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36688.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36688


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 36688] - Using var expansion in include tags fails in javac

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36688.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36688


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-09-16 18:25 ---
I cannot reproduce this (additionally we do not support the var task in Ant 
proper).  If you can create a self-contained example build file, you may reopen 
this bug and attach it so we can verify where the fault lies, or you can seek 
further advice on the user list.

Thanks

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: corrupt jar files and javac

2005-09-16 Thread Antoine Levy-Lambert

Hello Steve,
I am working in an environment where all makes are done with
duplicates=preserve. Now I think such a change does break BC.
BC is a huge advantage of ant. Where I am working, a lot of makes have
been switched from Ant 1.4 to Ant 1.6 with only 2 tiny problems,
which were a different behavior for user properties ( ant
-Dsomeprop=value) and one protected method of the Zip task which had
changed signature.

Cheers from Frankfurt,

Antoine

Steve Loughran wrote:

 Steve Loughran wrote:


 I would guess from this trace that there is a bad JAR file somewhere
 in my (long, convoluted, m2-tasks created) classpath, something
 breaking javac.

 the problem of course is that javac isnt helpful enough to tell me
 which file. I have tried unzipping everything, but of course, ant's
 unzip task doesnt complain at all, and nor, apparently, does jar
 and exec executable=jar /.

 what else do I have to track this down?

 compile:
[depend] The class
 org.smartfrog.services.deployapi.transport.config.Axis2ServiceImpl_Stub
 in file
 /home/slo/Projects/SmartFrog/Forge/core/components/deployapi/build/classes/org/smartfrog/services/deployapi/transport/config/Axis2ServiceImpl_Stub.class
 is out of date due to
 org.smartfrog.services.deployapi.transport.config.Axis2Service but
 has not been deleted because its source file could not be determined
 [core:javac] Compiling 13 source files to
 /home/slo/Projects/SmartFrog/Forge/core/components/deployapi/build/classes

 [core:javac] java.lang.IndexOutOfBoundsException
 [core:javac] at
 java.util.zip.InflaterInputStream.read(InflaterInputStream.java:122)
 [core:javac] at 


 The corruption is caused by duplicate .class files in the JAR.
 Fortunately it was one of my projects, and by changing the presetdef
 for jar to default=preserve and rebulding it went away. If the
 defect was in a JAR file that I was autoloading from the network
 repositories, I would have been stuffed.

 Why dont we set default=preserve rather than default=add on the
 zip tasks, on the basis that it may break BC, but it is probably a bug
 to have this problem anyway?

 -steve



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: corrupt jar files and javac

2005-09-16 Thread Stefan Bodewig

On Fri, 16 Sep 2005, Steve Loughran [EMAIL PROTECTED] wrote:

 Why dont we set default=preserve rather than default=add on the
 zip tasks, on the basis that it may break BC, but it is probably a
 bug to have this problem anyway?

I know I closed a bug report with similar symptoms a while ago.  Yes,
BC was the reason.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 36688] - Using var expansion in include tags fails in javac

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36688.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36688





--- Additional Comments From [EMAIL PROTECTED]  2005-09-17 02:40 ---
It may be helpful to know I am using JDK 1.3.1_02.  I do not have the option to
use a newer JDK for the product I am supporting.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 36056] - Manual mistake true for on value of debug attribute in javac

2005-08-10 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36056.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36056


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |NEEDINFO
Summary|Manual mistake true for   |Manual mistake true for
   |on value of debug |on value of debug
   |attribute in javac  |attribute in javac




--- Additional Comments From [EMAIL PROTECTED]  2005-08-10 20:48 ---
no. this has to be something else. Ant maps true/yes to a boolean value taken by
the task's setter. Please post your (failing) task declaration so we can see
what the real problem is. 

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 36056] New: - Manual mistake true for on value of debug attribute in javac

2005-08-05 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36056.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36056

   Summary: Manual mistake true for on value of debug attribute
in javac
   Product: Ant
   Version: 1.6.5
  Platform: Other
   URL: http://ant.apache.org/manual/CoreTasks/javac.html
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Documentation
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]


As in summary.

Using ant, it seems that true does not works.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35891] New: - Task Javac doesn't include javac -X options of JDK 1.5

2005-07-27 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35891.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35891

   Summary: Task Javac doesn't include javac -X options of JDK 1.5
   Product: Ant
   Version: 1.6.5
  Platform: PC
OS/Version: Windows 2000
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Core tasks
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]


Task Javac doesn't include javac -X options of JDK 1.5,so I can't use 
-Xlint:unchecked param to examine my code

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35891] - Task Javac doesn't include javac -X options of JDK 1.5

2005-07-27 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35891.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35891


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME
Summary|Task Javac doesn't include  |Task Javac doesn't include
   |javac -X options of JDK 1.5 |javac -X options of JDK 1.5




--- Additional Comments From [EMAIL PROTECTED]  2005-07-27 13:07 ---
Task javac has compilerarg element precisely  because different compilers have
different options

compilerarg value=-Xlint:unchecked 

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35637] - Allow javac to set property when compile fails

2005-07-20 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35637.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35637





--- Additional Comments From [EMAIL PROTECTED]  2005-07-20 22:22 ---
Created an attachment (id=15724)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15724action=view)
patch to add a failure property to be set if javac fails

my first patch... not sure if I need to do more than this... :-)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: javac

2005-07-13 Thread Jean Lazarou

Ok, you approach is fine, even if it doesn't fit my situation as I should find 
at what *levels* of the tree structure I should apply your idea.
 
If you look at the Javac Task implementation you can see that it is not far 
from beeing an API, the Javac developer could publish that his/her 
implementation (1) finds all the files to compile, in the execute method, 
storing the result in a *protected* variable (not a private like some other 
variables) (2) calls the compile method... from a OO perspective it looks like 
an invitation to extension.
 
With open-source you can spend time to look at the code and learn how people 
implemented things... and then have ideas on how to add custom things. If later 
on the new stuffs can help anyone, it's better. That's the reason I registered 
myself on this list. To share what I did, in case others think it would be of 
any interrest. 
 
The extension I made could be a parameter in the nomal Javac implementation, 
like beeing able to pick up the right compilation strategy. So, not having the 
problem you described with new versions.
 
Regards,
 
Jean
 

Kenneth Wood [EMAIL PROTECTED] wrote:
Just FYI, I have legacy code I need to compile, I have been
building it with ant for years... 

I just structure my build.xml to compile sections, 
i.e. includes=Z/**/*.java/

includes=Y/**/*.java/

And so on for 26 sections!

It has worked fine...

Ugly, yes. But, it doesn't require extensions to Ant, which
can be problematic when moving from one version of Ant to
another (and this code started out being compiled with
Ant 1.1 maybe - so long ago I don't remember and now is
up to Ant 1.6.1)


-Original Message-
From: Jean Lazarou [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 12, 2005 9:53 AM
To: Ant Developers List
Subject: RE: javac


Do you think we can pick up any splitting for the subsystem to compile?

How can you be sure, when you're not developer of the project, that some
sub-tree won't imply that, due to compilation dependencies, again too
much files to compile at once? Even the approach I wrote is not full
reliable... 

Any way, creating a new task that derives from the ant Javac task
implemention was pretty easy to do.

I thank you for you advice.

Jean


Dominique Devienne 
   wrote:
Phil is right Jean. Independently of splitting the code in subsystems,
which is always a good idea, even if you can't do that you can split the
compile of a single source tree into several passes using regular . This
can even enforce dependencies of the code compiled by the different
passes. The trick is to reset the sourcepath that normally sets.

I include here an example for reference. Hope this helps. --DD

Compile the java code from src/ into build/classes
--





when not forking , and instead specify directly the
JVM argument only when forking... Convoluted, but works! --

















destdir=@{destdir} sourcepath=
deprecation=${deprecation} debug=true verbose=false
includeAntRuntime=false fork=@{fork} --






























 -Original Message-
 From: Phil Weighill Smith [mailto:[EMAIL PROTECTED]
 
 Why not simply put two calls to javac in your build script and split 
 the source tree in two in the same way that you have in your new task,

 passing one tree to the first call and the other to the second?
 
 Clearly you need to ensure that the first call compiles 
 pre-requisite code for the second call and that you should avoid 
 cyclic references between the two sets of classes.
 
 On Tue, 2005-07-12 at 00:12 -0700, Jean Lazarou wrote:
  We had problem with a (legacy) build from scratch, seems that, 
  because
 we have too many java files to compile, nothing is compiled (both on 
 Linux and Windfoos2000).
 
  After spending 4 days on that, I decided to split the compilation, I
 created a new task, name bydir-javac. The task is derived from 
 Javac.
 
  Can I publish this? Is it a better way of doing it?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
 Start your day with Yahoo! - make it your home page

javac

2005-07-12 Thread Jean Lazarou

We had problem with a (legacy) build from scratch, seems that, because we have 
too many java files to compile, nothing is compiled (both on Linux and 
Windows2000). 
 
After spending 4 days on that, I decided to split the compilation, I created a 
new task, name bydir-javac. The task is derived from Javac.
 
Can I publish this? Is it a better way of doing it?
 
Jean Lazarou

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

Re: javac

2005-07-12 Thread Phil Weighill Smith

Why not simply put two calls to javac in your build script and split the
source tree in two in the same way that you have in your new task,
passing one tree to the first call and the other to the second?

Clearly you need to ensure that the first call compiles pre-requisite
code for the second call and that you should avoid cyclic references
between the two sets of classes.

Phil :n.

PS: I would consider re-structuring the application into subsystems
with separate source trees and separate build scripts per subsystem.
Dependencies between subsystems only on the class files (not the source
files). This is the approach we have taken to great effect.

On Tue, 2005-07-12 at 00:12 -0700, Jean Lazarou wrote:
 We had problem with a (legacy) build from scratch, seems that, because we 
 have too many java files to compile, nothing is compiled (both on Linux and 
 Windows2000). 
  
 After spending 4 days on that, I decided to split the compilation, I created 
 a new task, name bydir-javac. The task is derived from Javac.
  
 Can I publish this? Is it a better way of doing it?
  
 Jean Lazarou
 
 __
 Do You Yahoo!?
 Tired of spam?  Yahoo! Mail has the best spam protection around 
 http://mail.yahoo.com 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: javac

2005-07-12 Thread Peter Reilly

It may be better to give more memory to the compiler.
With enough memory a hugh number of files can be
compiled. The default memory is only I think 64M.

This can be done in a number of ways -

- use the env variable ANT_OPTS to specify the memory
for Ant's jvm
example: export ANT_OPTS=-Xms200m -Xmx1000m
in your .bashrc file
- spawn a jvm for the compiler
javac srcdir=${src}
destdir=${build}
fork=true memoryInitialSize=100m
memoryMaximumSize=1000m/

In extreme cases you can split the code into functional units
and compile each separately. This would not be at the level of
directories, but complete package trees. We had to do this
in a project once.

Peter

Jean Lazarou wrote:

We are trying to create an ant build for legacy code, that is build using some
make tool, as I don't want to break the already complicated buiild, I preferred
simulate the same behaviour as the make tool we're using. As that legacy code
is still alive I cannot count the files and decide how to split because it
could break in several months.

Jean

Phil Weighill Smith [EMAIL PROTECTED] wrote:
Why not simply put two calls to javac in your build script and split the
source tree in two in the same way that you have in your new task,
passing one tree to the first call and the other to the second?

Clearly you need to ensure that the first call compiles pre-requisite
code for the second call and that you should avoid cyclic references
between the two sets of classes.

Phil :n.

PS: I would consider re-structuring the application into subsystems
with separate source trees and separate build scripts per subsystem.
Dependencies between subsystems only on the class files (not the source
files). This is the approach we have taken to great effect.

On Tue, 2005-07-12 at 00:12 -0700, Jean Lazarou wrote:

We had problem with a (legacy) build from scratch, seems that, because we have too many java files to compile, nothing is compiled (both on Linux and Windows2000).

After spending 4 days on that, I decided to split the compilation, I created a new task,
name bydir-javac. The task is derived from Javac.

Can I publish this? Is it a better way of doing it?

Jean Lazarou

__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: javac

2005-07-12 Thread Jean Lazarou

We changed the memory size, using the ways you described, but the build still 
failed.
 
The problem with splitting in functional units is that the development is done 
on several sites with several teams, and the final build made by us... we don't 
want to change that strange process because that development is the legacy code 
maintainance, new developments are structured differently and we don't run into 
the same problems. But, we want to have all the builds made using ant.
 
Jean

Peter Reilly [EMAIL PROTECTED] wrote:
It may be better to give more memory to the compiler.
With enough memory a hugh number of files can be
compiled. The default memory is only I think 64M.

This can be done in a number of ways -

- use the env variable ANT_OPTS to specify the memory
for Ant's jvm
example: export ANT_OPTS=-Xms200m -Xmx1000m
in your .bashrc file
- spawn a jvm for the compiler
destdir=${build}
fork=true memoryInitialSize=100m
memoryMaximumSize=1000m/

In extreme cases you can split the code into functional units
and compile each separately. This would not be at the level of
directories, but complete package trees. We had to do this
in a project once.

Peter 

Jean Lazarou wrote:

We are trying to create an ant build for legacy code, that is build using some 
make tool, as I don't want to break the already complicated buiild, I 
preferred simulate the same behaviour as the make tool we're using. As that 
legacy code is still alive I cannot count the files and decide how to split 
because it could break in several months.
 
Jean


Phil Weighill Smith 
wrote:
Why not simply put two calls to javac in your build script and split the
source tree in two in the same way that you have in your new task,
passing one tree to the first call and the other to the second?

Clearly you need to ensure that the first call compiles pre-requisite
code for the second call and that you should avoid cyclic references
between the two sets of classes.

Phil :n.

PS: I would consider re-structuring the application into subsystems
with separate source trees and separate build scripts per subsystem.
Dependencies between subsystems only on the class files (not the source
files). This is the approach we have taken to great effect.

On Tue, 2005-07-12 at 00:12 -0700, Jean Lazarou wrote:
 

We had problem with a (legacy) build from scratch, seems that, because we 
have too many java files to compile, nothing is compiled (both on Linux and 
Windows2000). 

After spending 4 days on that, I decided to split the compilation, I created 
a new task, name bydir-javac. The task is derived from Javac.

Can I publish this? Is it a better way of doing it?

Jean Lazarou

__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

Re: javac

2005-07-12 Thread Peter Reilly

Ok
I still think that it would be better to try to modularize it, however
it is fair enough the deal with the problem using the least amount
of effort!.

Cheers,
Peter

Jean Lazarou wrote:

We changed the memory size, using the ways you described, but the build still
failed.

The problem with splitting in functional units is that the development is done
on several sites with several teams, and the final build made by us... we don't
want to change that strange process because that development is the legacy code
maintainance, new developments are structured differently and we don't run into
the same problems. But, we want to have all the builds made using ant.

Jean

Peter Reilly [EMAIL PROTECTED] wrote:
It may be better to give more memory to the compiler.
With enough memory a hugh number of files can be
compiled. The default memory is only I think 64M.

This can be done in a number of ways -

- use the env variable ANT_OPTS to specify the memory
for Ant's jvm
example: export ANT_OPTS=-Xms200m -Xmx1000m
in your .bashrc file
- spawn a jvm for the compiler
destdir=${build}
fork=true memoryInitialSize=100m
memoryMaximumSize=1000m/

Peter

Jean Lazarou wrote:

Jean

Phil Weighill Smith

wrote:

Why not simply put two calls to javac in your build script and split the
source tree in two in the same way that you have in your new task,
passing one tree to the first call and the other to the second?

Clearly you need to ensure that the first call compiles pre-requisite
code for the second call and that you should avoid cyclic references
between the two sets of classes.

Phil :n.

On Tue, 2005-07-12 at 00:12 -0700, Jean Lazarou wrote:

We had problem with a (legacy) build from scratch, seems that, because we have too many java files to compile, nothing is compiled (both on Linux and Windows2000).

After spending 4 days on that, I decided to split the compilation, I created a new task,
name bydir-javac. The task is derived from Javac.

Can I publish this? Is it a better way of doing it?

Jean Lazarou

__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: javac

2005-07-12 Thread Dominique Devienne

Phil is right Jean. Independently of splitting the code in subsystems, which
is always a good idea, even if you can't do that you can split the compile
of a single source tree into several passes using regular javac. This can
even enforce dependencies of the code compiled by the different passes. The
trick is to reset the sourcepath that javac normally sets.

I include here an example for reference. Hope this helps. --DD

  !-- =
   Compile the java code from src/ into build/classes
--
  target name=-classes

mkdir dir=build/classes/META-INF /
mkdir dir=build/testclasses /

!-- Avoid warning message about memoryMaximumSize being ignored
 when not forking javac, and instead specify directly the
 JVM argument only when forking... Convoluted, but works!  --
property name=javac.memoryMaximumSize.true value=-J-Xmx512m /
property name=javac.memoryMaximumSize.false value= /

property name=deprecation value=true /

macrodef name=compile
  attribute name=fork default=false /
  attribute name=srcdir default=src /
  attribute name=destdir default=build/classes /
  element name=sources implicit=true optional=true /
  sequential
javac srcdir=@{srcdir} source=1.4
   destdir=@{destdir} sourcepath=
   deprecation=${deprecation} debug=true verbose=false
   includeAntRuntime=false fork=@{fork}
  !-- equivalent to javac ... memoryMaximumSize=512m --
  compilerarg line=[EMAIL PROTECTED] /
  classpath refid=classpath /
  sources/
/javac
  /sequential
/macrodef

!-- compile FOO first, --
compile fork=true
  include name=com/acme/foo/** /
  include name=com/acme/app/foo/** /
/compile

!-- then BAR, --
compile
  include name=com/acme/bar/** /
  include name=com/acme/app/bar/** /
  include name=com/acme/testing/utils/TestAlgo*.java /
/compile

!-- then the package-private tests, --
compile srcdir=test destdir=build/testclasses /

!-- and finally the examples. --
compile
  include name=com/acme/examples/** /
/compile

  /target

 -Original Message-
 From: Phil Weighill Smith [mailto:[EMAIL PROTECTED]
 
 Why not simply put two calls to javac in your build script and split the
 source tree in two in the same way that you have in your new task,
 passing one tree to the first call and the other to the second?
 
 Clearly you need to ensure that the first call compiles pre-requisite
 code for the second call and that you should avoid cyclic references
 between the two sets of classes.
 
 On Tue, 2005-07-12 at 00:12 -0700, Jean Lazarou wrote:
  We had problem with a (legacy) build from scratch, seems that, because
 we have too many java files to compile, nothing is compiled (both on Linux
 and Windfoos2000).
 
  After spending 4 days on that, I decided to split the compilation, I
 created a new task, name bydir-javac. The task is derived from Javac.
 
  Can I publish this? Is it a better way of doing it?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: javac

2005-07-12 Thread Jean Lazarou

Do you think we can pick up any splitting for the subsystem to compile?
 
How can you be sure, when you're not developer of the project, that some 
sub-tree won't imply that, due to compilation dependencies, again too much 
files to compile at once?
Even the approach I wrote is not full reliable... 
 
Any way, creating a new task that derives from the ant Javac task implemention 
was pretty easy to do.
 
I thank you for you advice.
 
Jean


Dominique Devienne [EMAIL PROTECTED] wrote:
Phil is right Jean. Independently of splitting the code in subsystems, which
is always a good idea, even if you can't do that you can split the compile
of a single source tree into several passes using regular . This can
even enforce dependencies of the code compiled by the different passes. The
trick is to reset the sourcepath that normally sets.

I include here an example for reference. Hope this helps. --DD

   Compile the java code from src/ into build/classes
--





 when not forking , and instead specify directly the
 JVM argument only when forking... Convoluted, but works!  --

















destdir=@{destdir} sourcepath=
deprecation=${deprecation} debug=true verbose=false
includeAntRuntime=false fork=@{fork}
 --






























 -Original Message-
 From: Phil Weighill Smith [mailto:[EMAIL PROTECTED]
 
 Why not simply put two calls to javac in your build script and split the
 source tree in two in the same way that you have in your new task,
 passing one tree to the first call and the other to the second?
 
 Clearly you need to ensure that the first call compiles pre-requisite
 code for the second call and that you should avoid cyclic references
 between the two sets of classes.
 
 On Tue, 2005-07-12 at 00:12 -0700, Jean Lazarou wrote:
  We had problem with a (legacy) build from scratch, seems that, because
 we have too many java files to compile, nothing is compiled (both on Linux
 and Windfoos2000).
 
  After spending 4 days on that, I decided to split the compilation, I
 created a new task, name bydir-javac. The task is derived from Javac.
 
  Can I publish this? Is it a better way of doing it?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

RE: javac

2005-07-12 Thread Kenneth Wood

Just FYI, I have legacy code I need to compile, I have been
building it with ant for years... 

I just structure my build.xml to compile sections, 
i.e. javac srcdir=com.abc 
   includes=Z/**/*.java/

 javac srcdir=com.abc 
includes=Y/**/*.java/

And so on for 26 sections!

It has worked fine...

Ugly, yes. But, it doesn't require extensions to Ant, which
can be problematic when moving from one version of Ant to
another (and this code started out being compiled with
Ant 1.1 maybe - so long ago I don't remember and now is
up to Ant 1.6.1)


-Original Message-
From: Jean Lazarou [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 12, 2005 9:53 AM
To: Ant Developers List
Subject: RE: javac


Do you think we can pick up any splitting for the subsystem to compile?
 
How can you be sure, when you're not developer of the project, that some
sub-tree won't imply that, due to compilation dependencies, again too
much files to compile at once? Even the approach I wrote is not full
reliable... 
 
Any way, creating a new task that derives from the ant Javac task
implemention was pretty easy to do.
 
I thank you for you advice.
 
Jean


Dominique Devienne [EMAIL PROTECTED] wrote:
Phil is right Jean. Independently of splitting the code in subsystems,
which is always a good idea, even if you can't do that you can split the
compile of a single source tree into several passes using regular . This
can even enforce dependencies of the code compiled by the different
passes. The trick is to reset the sourcepath that normally sets.

I include here an example for reference. Hope this helps. --DD

   Compile the java code from src/ into build/classes
--





 when not forking , and instead specify directly the
 JVM argument only when forking... Convoluted, but works!  --

















destdir=@{destdir} sourcepath=
deprecation=${deprecation} debug=true verbose=false
includeAntRuntime=false fork=@{fork}  --






























 -Original Message-
 From: Phil Weighill Smith [mailto:[EMAIL PROTECTED]
 
 Why not simply put two calls to javac in your build script and split 
 the source tree in two in the same way that you have in your new task,

 passing one tree to the first call and the other to the second?
 
 Clearly you need to ensure that the first call compiles 
 pre-requisite code for the second call and that you should avoid 
 cyclic references between the two sets of classes.
 
 On Tue, 2005-07-12 at 00:12 -0700, Jean Lazarou wrote:
  We had problem with a (legacy) build from scratch, seems that, 
  because
 we have too many java files to compile, nothing is compiled (both on 
 Linux and Windfoos2000).
 
  After spending 4 days on that, I decided to split the compilation, I
 created a new task, name bydir-javac. The task is derived from 
 Javac.
 
  Can I publish this? Is it a better way of doing it?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35637] New: - Allow javac to set property when compile fails

2005-07-06 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35637.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35637

   Summary: Allow javac to set property when compile fails
   Product: Ant
   Version: unspecified
  Platform: Other
OS/Version: other
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Core tasks
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]


When javac tasks fail, it can fail the build, or not fail the build.  Would like
to have the ability to set a property on failure.  (Useful for later detection,
instead of immediate abort.)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35637] - Allow javac to set property when compile fails

2005-07-06 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35637.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35637





--- Additional Comments From [EMAIL PROTECTED]  2005-07-07 01:58 ---
Have you tried trycatch 
http://ant-contrib.sourceforge.net/tasks/tasks/trycatch.html ?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35590] - Request: control source/target of javac through a property

2005-07-05 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35590.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35590





--- Additional Comments From [EMAIL PROTECTED]  2005-07-05 19:55 ---
I didn't say that, Martijn did! :)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35590] - Request: control source/target of javac through a property

2005-07-03 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35590.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35590





--- Additional Comments From [EMAIL PROTECTED]  2005-07-04 01:57 ---
Your suggestion is definately a possibility, and if it was a project that I was
working on, I would go with that.

However, from the perspective of a packager, it's one more thing to patch and
another patch to maintain. Now, with defining which compiler to use, its easy
enough to define build.compiler either on the command line or in a properties
file. It would be nice to have similar way to define which VM version class
files should work with.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35590] - Request: control source/target of javac through a property

2005-07-03 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35590.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35590





--- Additional Comments From [EMAIL PROTECTED]  2005-07-04 02:43 ---
You can create the following bulid script that copies the original build script
and adds presetdef. The script uses ANT Contrib and assumes there is a space
character (including newline) after project.

Run it before executing the real build (maybe by creating a shell script), then
run ANT with new buildscript with giver parameters:

?xml version=1.0 encoding=iso-8859-1?
project name=smartbuild default=all basedir=.
  taskdef resource=net/sf/antcontrib/antcontrib.properties
classpath
  pathelement location=lib/ant-contrib.jar/
/classpath
  /taskdef

  target name=all
ifnotuptodate srcfile=build.xml targetfile=updated.xml//not
  then
copy file=build.xml tofile=updated.xml/
replaceregexp file=updated.xml match=(lt;project.*?)(\s)
replace=\1lt;presetdef name=quot;javacquot;lt;javac
compiler=quot;$${build.compiler}quot;/lt;/presetdef\2/
  /then
/if
  /target
/project

This is a batch script that can be used to executed updated build:

#!/bin/bash
ant -f build2.xml
ant -f updated.xml $@

With ANT, you can execute the target and then execute ant with updated file.

- Alexey.




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35590] - Request: control source/target of javac through a property

2005-07-03 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35590.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35590





--- Additional Comments From [EMAIL PROTECTED]  2005-07-04 07:47 ---
 Now, with defining which compiler to use, its easy
 enough to define build.compiler either on the command line or in a 
 properties file. It would be nice to have similar way to define which 
 VM version class files should work with.

build.xml
project
property file=build.properties/

!-- set defaults --
property name=javac.source value=1.4/
property name=javac.target value=1.4/

javac source=${javac.source} target=${javac.target} ...


build.properties
javac.source=1.3
javac.target=1.3


Could also be override on startup
ant -Djavac.source=1.5 -Djavac.target=1.5



All like Matt said. 
Where is the problem?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35590] New: - Request: control source/target of javac through a property

2005-07-02 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35590.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35590

   Summary: Request: control source/target of javac through a
property
   Product: Ant
   Version: unspecified
  Platform: Other
OS/Version: other
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Core tasks
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]


Seeing as it is possible to specify the compiler javac uses through
build.compiler, I think it would be extremely useful to be able to control
which  VM version to generate class files for. This would be of particular
interest to downstream packagers, in order to finely tune which VM versions a
package would be compiled for.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35590] - Request: control source/target of javac through a property

2005-07-02 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35590.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35590


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |NEEDINFO




--- Additional Comments From [EMAIL PROTECTED]  2005-07-02 22:57 ---
From the manual on javac:

target  

Generate class files for specific VM version (e.g., 1.1 or 1.2). Note that the
default value depends on the JVM that is running Ant. In particular, if you use
JDK 1.4+ the generated classes will not be usable for a 1.1 Java VM unless you
explicitly set this attribute to the value 1.1 (which is the default value for
JDK 1.1 to 1.3). We highly recommend to always specify this attribute.

and the example
  javac srcdir=${src}
 destdir=${build}
 fork=true
 source=1.2
 target=1.2
  /

Please state why this is not sufficient? (one could replace
target=1.2 by target=${destversion}

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35325] - javac: properties for default source and target version

2005-06-11 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35325.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35325


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2005-06-11 08:46 ---
IMHO people using javac should always specify source (which implies a
reasonable target as well). If you wrote the sources, you know what source level
they use, so you should declare it. There is no reason I can see to make this
variable dependent on system config. (Obviously if some project is using a
source level higher than that supported by the compiler Ant is running, you are
in trouble, but using a magic value for the source level would just give you
compiler errors anyway.)

BTW the javac doc page already recommends that source always be explicit.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35325] New: - javac: properties for default source and target version

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35325.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35325

   Summary: javac: properties for default source and target version
   Product: Ant
   Version: 1.6.2
  Platform: All
   URL: https://bugs.gentoo.org/show_bug.cgi?id=86903
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Core tasks
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]


I'd like to suggest an enhancement. Take default values for the source and
target arguments to the javac core task from properties, e.g. build.source
and build.target. This would allow creators of packages for distributions
(e.g. Gentoo in my case) to specify or change those properties according to
system configuration without modifying the build.xml file.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35325] - javac: properties for default source and target version

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35325.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35325


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME




--- Additional Comments From [EMAIL PROTECTED]  2005-06-11 01:40 ---
Please see presetdef documentation at 
  http://ant.apache.org/manual/CoreTasks/presetdef.html.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35325] - javac: properties for default source and target version

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35325.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35325





--- Additional Comments From [EMAIL PROTECTED]  2005-06-11 02:06 ---
I was thinking about a project with a build.xml that was written by someone
else, doesn't provide any version information at all, and I don't want to modify
the build file itself and still be able to compile the project with reasonable
defaults for my system.

In this case you'd either have to rewrite the build.xml to introduce those
attrributes or to introduce using the presetdef defined task instead of the
plain javac. I don't see much difference between those two approaches.

Or is there a way to override core tasks by modified versions in an antlib by
just using command line arguments?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35325] - javac: properties for default source and target version

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35325.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35325





--- Additional Comments From [EMAIL PROTECTED]  2005-06-11 02:15 ---
You can create a separate build file with presetdef and import of the old 
build file.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35325] - javac: properties for default source and target version