Re: javac task problem in Java 6
Jesse Glick wrote: Jess Holle wrote: We've seen this before where A depends on B which /internally/ depends upon C and then suddenly one has to have C around to compile A. Although this is not forbidden by the JLS (as far as I know), it does seem undesirable. If you know of particular examples which can be expressed as minimal test cases, I would encourage you to file bug reports for the compiler. Not ever seen that. I have just been burned today by the fact that Java6 lets you do an @Overrides on any method that implements an interface; I'd been using that to indicate which methods were interface implementations. Java5 says @Overrides is only for non-abstract methods, hence breaks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javac task problem in Java 6
Steve Loughran wrote: Jesse Glick wrote: Jess Holle wrote: We've seen this before where A depends on B which /internally/ depends upon C and then suddenly one has to have C around to compile A. Although this is not forbidden by the JLS (as far as I know), it does seem undesirable. If you know of particular examples which can be expressed as minimal test cases, I would encourage you to file bug reports for the compiler. Not ever seen that. I have just been burned today by the fact that Java6 lets you do an @Overrides on any method that implements an interface; I'd been using that to indicate which methods were interface implementations. Java5 says @Overrides is only for non-abstract methods, hence breaks. Yes, that's a really obnoxious failing in Java 5. It's good that it was fixed in Java 6. It would have been even better if it had been fixed in a Java 5 update. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javac task problem in Java 6
Hi Stefan! I followed your advice and set sourcepath to . Compilation by javac works properly in JDK 5 and 6: javac -sourcepath -classpath b.jar A.java Compilation by ant task works properly in JDK 5, but does not work in JDK 6: project default=compile target name=compile javac sourcepath= srcdir = . destdir=. includes=A.java excludes=B.java classpath pathelement path=b.jar/ /classpath /javac /target /project So there is a problem in the way Ant works with javac. I understand that Ant compiles classes using tools.jar, so there is no straight way to write the same command line. But since JDK javac compiler works properly in both JDK, I suppose that something is wrong in Ant's javac task. Is it correct? BTW, did you try to compile classes from javac_issue.zip that I had sent earlier? Regards, Sergey Bondarenko. 2008/11/5 Stefan Bodewig [EMAIL PROTECTED] On Tue, 4 Nov 2008, Sergey Bondarenko [EMAIL PROTECTED] wrote: javac -sourcepath A.java -classpath b.jar A.java It works properly in both JDK 5 and 6. This is not what Ant does (and why I pointed you at sourcepath= in order to get something like that. But Ant's javac task with includes and excludes does not work with JDK 6. See my response. So I am not sure that problem is in javac compiler. It looks like there is a problem in javac Ant task. Could anybody please check it? Is there any way to look at exact javac invocation string that is produced for the build script? Run Ant with -verbose. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javac task problem in Java 6
On Wed, 5 Nov 2008, Sergey Bondarenko [EMAIL PROTECTED] wrote: Hi Stefan! I followed your advice and set sourcepath to . Compilation by javac works properly in JDK 5 and 6: javac -sourcepath -classpath b.jar A.java Compilation by ant task works properly in JDK 5, but does not work in JDK 6 This is not what Ant does. Compilation looks more like javac -d . -sourcepath . -classpath b.jar A.java without setting sourcepath (Ant uses srcdir as sourcepath in that case) and javac -d . -classpath b.jar A.java with sourcepath=. The problem seems to be that destdir==srcdir in your case. If I create a directory d and set destdir=d then only A gets compiled (on Java4 as well as Java5). It seems as if Java6's javac searches the destination directory for sources as well. I understand that Ant compiles classes using tools.jar, so there is no straight way to write the same command line. If you set fork=true it will use the command line, but the in-process execution really should look the same. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javac task problem in Java 6
Jess Holle wrote: We've seen this before where A depends on B which /internally/ depends upon C and then suddenly one has to have C around to compile A. Although this is not forbidden by the JLS (as far as I know), it does seem undesirable. If you know of particular examples which can be expressed as minimal test cases, I would encourage you to file bug reports for the compiler. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javac task problem in Java 6
Well, I tried javac:
javac -sourcepath A.java -classpath b.jar A.java
It works properly in both JDK 5 and 6.
But Ant's javac task with includes and excludes does not work with JDK
6.
So I am not sure that problem is in javac compiler. It looks like there is a
problem in javac Ant task.
Could anybody please check it?
Is there any way to look at exact javac invocation string that is produced
for the build script?
Regards,
Sergey Bondarenko.
2008/11/4 Jess Holle [EMAIL PROTECTED]
I am rather certain this is a javac bug -- though it would be good to
/prove /that from a javac command line so as to get some focus on the real
issue here.
I believe Sun should take this particular issue seriously. We've seen this
before where A depends on B which /internally/ depends upon C and then
suddenly one has to have C around to compile A. That extends compilation
dependencies across decoupling points one designs in and breaks library
opacity / encapsulation. This whole issue needs to be taken seriously and
nailed by Sun. It impacts Ant, of course, but this in turn impacts
NetBeans. It also impacts everything that uses their compiler rather than
JDT. Overall this issue should not be tolerated.
--
Jess Holle
Stefan Bodewig wrote:
On Tue, 4 Nov 2008, Sergey Bondarenko [EMAIL PROTECTED] wrote:
Regarding compilation issue, it looks like Ant javac task does not
handle includes and excludes attributes correctly when it is
used with JDK 6. But it works properly with JDK 5.
Uhm, no.
includes/excludes controls which source files are being sent to
javac's command line. If javac decides that it needs to compile
additional classes that it can find inside the source path, then there
is nothing that Ant can do.
Inside the manual page for the javac task you will find (under
examples):
,
| If you wish to compile only files explicitly specified and disable
| javac's default searching mechanism then you can unset the sourcepath
| attribute:
| | javac sourcepath= srcdir=${src}
| destdir=${build}
| include name=**/*.java/
| exclude name=**/Example.java/
| /javac
| | That way the javac will compile all java source files under ${src}
| directory but skip the examples. The compiler will even produce errors
| if some of the non-example files refers to them.
`
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: javac task problem in Java 6
On Tue, 4 Nov 2008, Sergey Bondarenko [EMAIL PROTECTED] wrote:
Regarding compilation issue, it looks like Ant javac task does not
handle includes and excludes attributes correctly when it is
used with JDK 6. But it works properly with JDK 5.
Uhm, no.
includes/excludes controls which source files are being sent to
javac's command line. If javac decides that it needs to compile
additional classes that it can find inside the source path, then there
is nothing that Ant can do.
Inside the manual page for the javac task you will find (under
examples):
,
| If you wish to compile only files explicitly specified and disable
| javac's default searching mechanism then you can unset the sourcepath
| attribute:
|
| javac sourcepath= srcdir=${src}
| destdir=${build}
| include name=**/*.java/
| exclude name=**/Example.java/
| /javac
|
| That way the javac will compile all java source files under ${src}
| directory but skip the examples. The compiler will even produce errors
| if some of the non-example files refers to them.
`
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: javac task problem in Java 6
On Tue, 4 Nov 2008, Sergey Bondarenko [EMAIL PROTECTED] wrote: javac -sourcepath A.java -classpath b.jar A.java It works properly in both JDK 5 and 6. This is not what Ant does (and why I pointed you at sourcepath= in order to get something like that. But Ant's javac task with includes and excludes does not work with JDK 6. See my response. So I am not sure that problem is in javac compiler. It looks like there is a problem in javac Ant task. Could anybody please check it? Is there any way to look at exact javac invocation string that is produced for the build script? Run Ant with -verbose. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javac task problem in Java 6
On Sat, 1 Nov 2008, Sergey Bondarenko [EMAIL PROTECTED] wrote: Any new regarding this issue? IMHO you are simply not sending your question to the set of people that could answer them. Based on your description the javac compilers behave differently, but Ant doesn't. I don't see how the Ant developers might help you. If you really think this is a bug in Ant, then please provide more information about your setup (how does A depend on B and B depend on C?). A self contained build file would be best. It would be good if you verified that running javac from the command line shows a different behavior than Ant. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javac task problem in Java 6
Sergey Bondarenko wrote: Imagine situation when you have 3 classes with dependencies between them: A - B - C Then you compile C.java and pack into c.jar Then you compile B.java, using c.jar in classpath, and pack it into b.jar Then you compile A.java, using b.jar. It works properly in Java 5, but fails in Java 6: compiler can not resolve dependency B-C (though you compile only A class). As Stefan said, this is likely not related to Ant as such. As far as I am aware, the JLS does not specify under which conditions a Java compiler might require transitive dependencies to be present on the classpath, beyond the obvious fact that if the content of such a dependency could possibly affect the generated bytecode then it must be present. I seem to recall that Jikes used to behave differently than javac, and I am not that surprised if JDK 5 javac behaves differently from JDK 6 javac. To be on the safe side, you should include c.jar in the classpath when compiling A.java. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javac task problem in Java 6
Any new regarding this issue? Thanks! Sergey. 2008/10/30 Sergey Bondarenko [EMAIL PROTECTED] Hi dear Ant developers! I think I found a bug in Ant javac task, (or maybe in Java compiler). I need you help to check if it is true. Javac task behaves differently in Java 6 and Java 5. For some reason it works properly in Java 5 on the same project structure, but fails in Java 6. Imagine situation when you have 3 classes with dependencies between them: A - B - C Then you compile C.java and pack into c.jar Then you compile B.java, using c.jar in classpath, and pack it into b.jar Then you compile A.java, using b.jar. It works properly in Java 5, but fails in Java 6: compiler can not resolve dependency B-C (though you compile only A class). I created simple test case, so could you please look at it and try to find out the cause of the problem? http://download.cl1p.net/javac_bug/?FILE=17647 There are two bat-files in archive: works.bat and fails.bat. The only difference between them is JDK version. I tried on Ant 1.7.1 and 1.6.5, using jdk1.6.0_10 and jdk1.5.0_16. The result is stable: compilation works on JDK 5, and fails on JDK 6. Any help is appreciated. Thanks! Regards, Sergey Bondarenko.
Re: javac task problem in Java 6
Sergey Bondarenko wrote: I created simple test case, so could you please look at it and try to find out the cause of the problem? http://download.cl1p.net/javac_bug/?FILE=17647 There are two bat-files in archive: works.bat and fails.bat. The only difference between them is JDK version. I don't have the same versions of the jdk as you (jdk1.5.0_06 jdk1.6.0_03 here), but here both these versions 'work'. There could of course be changes in your versions to cause the failure... ...May I suggest you invoke ant with -verbose -diagnostics, so you may check if there are any differences between the two invocations in your environment at all? Comparing the full output from each jdk may provide some clues. -- Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javac return status
euge wrote: May be it's not the place to write my question. If yes, I'm sorry. Why is it not allowed to put javac in condition tag? Is there any reason why it was not developed? or the developers did not just get to it yet? Asking just out of curiosity. Ant has a very simple view of the world. Either things compile, or they dont. Not compiling is an error and the build halts. Most tasks are like this, though a fair few have a failonerror to say ignore failures. junit does save its outcome, not because you want to ignore the failures, but to let you create junitreport output before failing. If you go to ant-contrib on sourceforge.net, you can pick up their try/catch tasks that let you catch a task failure. -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javac on java1.5
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
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
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
#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
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
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
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
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
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]
RE: javac
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
Re: javac
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
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
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
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/
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: javac
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
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
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]
Re: javac: target release 1.1 conflicts with default source release 1.5
Excelent! Peter Stefan Bodewig wrote: Hi, after I've been watching the JDK 1.5 builds of Gump for weeks now, I've pretty much given up the hope that projects are going to adapt the build files to JDK 1.5 soon. Xalan's build breaks because they only specify the target attribute and quite a few others do so as well. (as a sidenote, Xalan's XSLT is supposed to be part of JDK 1.5, I find it slightly amusing that you can't build it with it). Finally I've come to the conclusion that Ant should take care of it. I therefore propose the following: IF * we are going to use JDK 1.5 for compiling * _and_ -target has been specified * _and_ -target is smaller than 1.5 * _and_ -source has not been specified THEN * print a big fat warning telling people to specify the source attribute. * implicitly set -source to the same value as -target. Since we don't know what JDK 1.6's javac's default is going to be I'd stick with handling the 1.5 case now. Anybody against applying this magic? Stefan - 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]
Re: javac: target release 1.1 conflicts with default source release 1.5
On Wed, 26 Jan 2005, Stefan Bodewig [EMAIL PROTECTED] wrote: * implicitly set -source to the same value as -target. didn't work as the current Gump run demonstrated. -source 1.1 is not supported. So the logic becomes * implicitly set -source to the same value as -target, unless it is 1.1 in which case we use 1.2 as value. Anybody against applying this magic? I have committed it to CVS HEAD and intend to document/merge it later this week. It should be trivial to revert if you don't like the idea. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javac and compilerargs
On Mon, 15 Mar 2004, Arnaud Vandyck [EMAIL PROTECTED] wrote: I'd like to make some changes in the ant-1.6.1/src/main/org/apache/tools/ant/taskdefs/compilers/Gcj.java task to change the behavior. I'd like ant NOT to pass the -C argument if a nested compilerarg tag exists. This is hard to do in a backwards compatible way. Honestly, I'm not sure how big our gcj user base is and how many of them use compilerarg to pass additional arguments, the answer could very well be zero. But if it is bigger than that, such a change would break their builds. Is there a command line argument that you'd always use when compiling to native code, like --main? If this was the case, we could silently omit -C if compiler args have been specified and one of them started with --main=. The only other solution I'd see would be a compiler specific magic property. Something like build.compiler.gcj.native and we'd drop -C if that property was set to true. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javac and compilerargs
Hi Stefan, Stefan Bodewig [EMAIL PROTECTED] writes: On Mon, 15 Mar 2004, Arnaud Vandyck [EMAIL PROTECTED] wrote: I'd like to make some changes in the ant-1.6.1/src/main/org/apache/tools/ant/taskdefs/compilers/Gcj.java task to change the behavior. I'd like ant NOT to pass the -C argument if a nested compilerarg tag exists. This is hard to do in a backwards compatible way. Honestly, I'm not sure how big our gcj user base is and how many of them use compilerarg to pass additional arguments, the answer could very well be zero. This is not a problem. I'll try to implement it myself and if the patch is not good for you, maybe we'll apply it only in Debian. Maybe we'll need it in a near future... we are not sure yet. But if it is bigger than that, such a change would break their builds. Isn't possible in the Gcj class to know if there is a nested compilerarg tag and look at the arguments of this tag? Is there a command line argument that you'd always use when compiling to native code, like --main? If this was the case, we could silently omit -C if compiler args have been specified and one of them started with --main=. --main and maybe '-o', I don't know, but I'll ask on gcj mailing list. The only other solution I'd see would be a compiler specific magic property. Something like build.compiler.gcj.native and we'd drop -C if that property was set to true. No problem for me if everything is well documented ;-) Seems to be a good solution. Can you point me were I have to patch such a possibility or will you do that? (I'm not in a hurry at all, it's a possible future project! ;-) ) Many thanks for your time and help, -- ~/.signature not found Packages should build-depend on what they should build-depend. -- Santiago Vila on debian-devel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: javac and compilerargs
The only other solution I'd see would be a compiler specific magic
property. Something like build.compiler.gcj.native and we'd drop -C
if that property was set to true.
No problem for me if everything is well documented ;-) Seems to be a
good solution. Can you point me were I have to patch such a
possibility
or will you do that? (I'm not in a hurry at all, it's a
possible future
project! ;-) )
Documentation is done by the task (see manual for javac).
E.g. the jikes adapter uses a magic property.
src/main/.../taskdefs/compiler/Jikes:
044: public boolean execute() throws BuildException {
078: // if the user has set JIKESPATH we should add the contents as
well
089:String jikesPath = System.getProperty(jikes.class.path);
080:if (jikesPath != null) {
081:classpath.append(new Path(project, jikesPath));
082:}
Jan
Re: javac and compilerargs
On Mon, 15 Mar 2004, Arnaud Vandyck [EMAIL PROTECTED] wrote: Stefan Bodewig [EMAIL PROTECTED] writes: Honestly, I'm not sure how big our gcj user base is and how many of them use compilerarg to pass additional arguments, the answer could very well be zero. This is not a problem. I'll try to implement it myself and if the patch is not good for you, maybe we'll apply it only in Debian. zero was my answer to the size of the user base I was talking about, not the chance of getting your patch into Ant 8-) Is there a command line argument that you'd always use when compiling to native code, like --main? If this was the case, we could silently omit -C if compiler args have been specified and one of them started with --main=. --main and maybe '-o', I don't know, but I'll ask on gcj mailing list. If you must use --main to compile native stuff and there is no way that -C can be used together with --main, that would be a really good indicator for Ant, wouldn't it? The question only is whether the assumption holds true. The gcj list will undoubtly know. The only other solution I'd see would be a compiler specific magic property. Something like build.compiler.gcj.native and we'd drop -C if that property was set to true. No problem for me if everything is well documented ;-) I'd say the solution is second best only. Especially since you can't reset a property once it is set. This would mean that you can't have a javac tasl that uses -C and one that doesn't in the same build process. Can you point me were I have to patch such a possibility Look around the src/main/org/apache/tools/ant/taskdefs/compiler directory. Jikes has some jikes specific magic properties for example. or will you do that? If I'd put it towards the end of my TODO list it would likely never get implemented ;-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javac and compilerargs
[EMAIL PROTECTED] writes: [...] 089: String jikesPath = System.getProperty(jikes.class.path); Huh! I thought it would be more complex! ;-) Thanks ;-) (but I think it'll be plan B ;-)) -- ~/.signature not found asuffield a workstation is anything you can stick on somebodies desk and con them into using -- in #debian-devel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javac and compilerargs
Stefan Bodewig [EMAIL PROTECTED] writes: On Mon, 15 Mar 2004, Arnaud Vandyck [EMAIL PROTECTED] wrote: Stefan Bodewig [EMAIL PROTECTED] writes: Honestly, I'm not sure how big our gcj user base is and how many of them use compilerarg to pass additional arguments, the answer could very well be zero. This is not a problem. I'll try to implement it myself and if the patch is not good for you, maybe we'll apply it only in Debian. zero was my answer to the size of the user base I was talking about, not the chance of getting your patch into Ant 8-) :-p snip/ Is it possible to know the value of compilerarg line=.../ when I am in the gcj class? If yes, how? ... reading the sources is a good thing to answer your own questions! ;-) (well I found your code very clear!) Is it OK if in the Gcj class, I do something like: String[] argsToTest = getJavac().getCurrentCompilerArgs(); Then I think I got to test if every String begins with -o or --main? If I'd put it towards the end of my TODO list it would likely never get implemented ;-) I hope I'll have the time and knowledge to do it ;-) Cheers, -- ~/.signature not found asuffield a workstation is anything you can stick on somebodies desk and con them into using -- in #debian-devel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javac and compilerargs
On Mon, 15 Mar 2004, Arnaud Vandyck [EMAIL PROTECTED] wrote: Is it OK if in the Gcj class, I do something like: String[] argsToTest = getJavac().getCurrentCompilerArgs(); Absolutely. The command line has been tokenized by Ant already, that is compilerarg line=--main=foo -o bar/ will become three array elements --main=foo, -o and bar. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javac and compilerargs
Stefan Bodewig [EMAIL PROTECTED] writes: On Mon, 15 Mar 2004, Arnaud Vandyck [EMAIL PROTECTED] wrote: Is it OK if in the Gcj class, I do something like: String[] argsToTest = getJavac().getCurrentCompilerArgs(); Absolutely. The command line has been tokenized by Ant already, that is compilerarg line=--main=foo -o bar/ will become three array elements --main=foo, -o and bar. I did it but I'm facing other problems. I can send the patch but the whole system is not working as I expect to do. I'll send a mail here when I got some result. Thanks for your informations, time and cooperation, Cheers, -- ~/.signature not found There are 3 types of guys -- the ones who hate nerds (all nerds, that is; girls aren't let off the hook); the ones who are scared off by girls who are slightly more intelligent than average; and the guys who are also somewhat more intelligent than average, but are so shy that they can't put 2 words together when they're within 20 feet of a girl. -- Vikki Roemer on debian-curiosa - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: javac-task and mapper
On Mon, 18 Aug 2003, didge [EMAIL PROTECTED] wrote: How about this? path id=sources dirset dir=src include name=team*/ /dirset /path javac ... src refid=sources/ /javac Yes, it works. Thanks Didge! So, there's no need for a mapper to solve my problem. Nevertheless, if there's interest for a mapper in javac... Call me and I'll be there. Ulf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: javac-task and mapper
On Mon, 18 Aug 2003, didge [EMAIL PROTECTED] wrote: How about this? path id=sources dirset dir=src include name=team*/ /dirset /path javac ... src refid=sources/ /javac Hm, looks good! Please give me some more time to investigate... (family-raid ;-) ) Ulf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: javac-task and mapper
On Mon, 18 Aug 2003, Dominique Devienne [EMAIL PROTECTED] wrote: All you need to do is: javac destdir=build src path=src/team1 / src path=src/team2 / /javac No need for a mapper. Works like a charm ;-) --DD This is true - as long as you know the names and the number of the teams. My wish is to create a single build.xml-file that is usable for all projects - no matter which teams are envolved. Ulf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: javac-task and mapper
Have you tried it? I haven't, but somehow I doubt it will work... That's just a guess though. --DD -Original Message- From: didge [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 19, 2003 7:14 PM To: Ant Developers List Subject: RE: javac-task and mapper How about this? path id=sources dirset dir=src include name=team*/ /dirset /path javac ... src refid=sources/ /javac didge -Original Message- From: Ulf Caspers [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 19, 2003 11:06 AM To: [EMAIL PROTECTED] Subject: RE: javac-task and mapper On Mon, 18 Aug 2003, Dominique Devienne [EMAIL PROTECTED] wrote: All you need to do is: javac destdir=build src path=src/team1 / src path=src/team2 / /javac No need for a mapper. Works like a charm ;-) --DD This is true - as long as you know the names and the number of the teams. My wish is to create a single build.xml-file that is usable for all projects - no matter which teams are envolved. Ulf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: javac-task and mapper
Have you tried it? I haven't, but somehow I doubt it will work... That's
just a guess though. --DD
It works, but I actually use a very different version in practice to achieve
something similar to Ulf's original wish: a way in which projects can
inherit common project behavior and yet still allow for optional extensions
or overrides.
First, some background: My projects generally have a single src subdirectory
where all .java files go. However, some projects use additional
subdirectories to contain the output of code generators. (I don't like to
mix source and generated code because it gets to annoying to figure out
which is which when they are colocated in the same directory.)
Therefore, I needed a way for a project to specify its source directories,
but I wanted to use a common set of targets for building. Let me tell you,
this was not easy to figure out. In much more than just a nutshell, this is
what I do:
Each project contains a build.xml minimally containing the target 'init'
which initializes a number of properties unique to the project: javadoc
name, jar name, version and a couple of other things. In addition, the
'init' target may also specify extensions to the default source and class
paths. By default, projects get default source and class paths of 'src' and
'build/classes:lib/*.jar:lib/*.zip'. For a project that wants to extend its
source path, to include 'gen' for example, then its 'init' target must
initialize a property containing the extended path.
This is achieved by constructing a path, called 'javac.sourcepath', composed
of the default source path (usually just 'src') and an extended source path,
if any.
This gets complicated, but essentially I have an XML fragment called
buildTargets.xml that defines my regular build targets and properties. This
fragment is included (via XML) into each project's build.xml that wants to
use it.
Here are the relevant portions of buildTargets.xml and a project's
build.xml, with an explanation following so you can get an idea how this
works:
buildTargets.xml:
target
name=buildTargets.setDefaultExtendedCompileSourcepath
unless=buildTargets.extended.javac.sourcepath
property name=buildTargets.extended.javac.sourcepath value=/
/target
target name=buildTargets.init
depends=init,
buildTargets.setDefaultExtendedCompileSourcepath
path id=javac.sourcepath
pathelement location=${builtTargets.javac.src.dir}/
pathelement path=${builtTargets.extended.javac.sourcepath}/
/path
/target
target name=compile depends=buildTargets.init
javac ...
src refid=buildTargets.javac.sourcepath/
/javac
/target
And here is an clip from one of my project build.xml files showing the
'init' and XML include:
!DOCTYPE project [
!ENTITY buildTargets SYSTEM file:../../ant/script/buildTargets.xml
]
target name=init
pathconvert
property=buildTargets.extended.javac.sourcepath
pathsep=${path.separator} dirsep=${file.separator}
path
pathelement location=gen/
/path
/pathconvert
/target
buildTargets;
How it works: Issuing the 'ant compile' command, results in the following
sequence of target being executed:
init
buildTargets.setDefaultExtendedCompileSourcepath
buildTargets.init
compile
As you can see, 'init' defines the extended sourcepath, and the next target
does nothing since the extended sourcepath was defined. 'buildTargets.init'
then merges the default sourcepath and the extended sourcepath into a single
property, ('javac.sourcepath') and 'compile' uses it. It is hopefully clear
then that if 'init' does not define an extension, then only the default
source path is used by 'compile'. (Note that it was necessary to ensure that
'buildTargets.extended.javac.sourcepath' is defined before
'buildTargets.init' is executed otherwise the path used to construct
'javac.sourcepath' can choke on an undefined property if the project does
not define an extended sourcepath.)
I've simplified things here a bunch to keep this as brief as possible and on
topic. However, there are a couple of other interesting features that my
scripts do as well:
1. Projects can override any target specified in buildTargets.xml, eg.
compile, clean, build, javadoc, etc. using indirect target references.
2. JDK specific classpaths and build tools are specifiable. This allows me
to easily build the same source against multiple JDK versions that may
require different sets of 3rd party libraries due to incompatibilities with
particular JDK versions.
I'd be happy to share more as people express interest.
didge
-Original Message-
From: Dominique Devienne [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 20, 2003 6:57 AM
To: 'Ant Developers List'
Subject: RE: javac-task and mapper
-Original Message-
From: didge [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 19, 2003 7:14 PM
To: Ant Developers List
Subject: RE: javac-task
Re: javac-task and mapper
On Mon, 18 Aug 2003, Stefan Bodewig [EMAIL PROTECTED] wrote: java or javac? javac! What would the mapper in javac be supposed to do? There is a GlobPatternMapper in the javac-taskdef which is fixed to map *.java-files to corresponding *.class-files. This is the reason why the source directory structure and the destination directory structure must match, which is usually no problem and what is expected by the java-compiler as well. Nevertheless there are situations in which this not the best case. I think about a source layout, where different packages are in different directories like this: src +--team1 ! +--com ! +--example !+--pack1 ! +--Class1.java ! +--Class2.java +--team2 +--com +--example +--pack2 +--ClassA.java +--ClassB.java But all packages should be compiled into a common directory like this: build +--com +--example +--pack1 ! +--Class1.class ! +--Class2.class +--pack2 +--ClassA.class +--ClassB.class The following task would compile all sources: javac srcdir=src destdir=build /javac But it would not be able to track unchanged *.java-files and does a recompile each time ant is invoked. Todays solution is either calling javac twice or copying all *.java-files to a common directory before calling javac. I guess it's faster and easier just to tell javac, how to find matching sources and output like this: javac srcdir=src destdir=build mapper type=regexp from=[^/]+/(.*)\.java to=\1.class/ /javac Of course mapper type=glob from*.java to=*.class/ will be the default. Do you think this makes sense? Ulf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: javac-task and mapper
All you need to do is: javac destdir=build src path=src/team1 / src path=src/team2 / /javac No need for a mapper. Works like a charm ;-) --DD -Original Message- From: Ulf Caspers [mailto:[EMAIL PROTECTED] Sent: Monday, August 18, 2003 4:35 PM To: [EMAIL PROTECTED] Subject: Re: javac-task and mapper On Mon, 18 Aug 2003, Stefan Bodewig [EMAIL PROTECTED] wrote: java or javac? javac! What would the mapper in javac be supposed to do? There is a GlobPatternMapper in the javac-taskdef which is fixed to map *.java-files to corresponding *.class-files. This is the reason why the source directory structure and the destination directory structure must match, which is usually no problem and what is expected by the java-compiler as well. Nevertheless there are situations in which this not the best case. I think about a source layout, where different packages are in different directories like this: src +--team1 ! +--com ! +--example !+--pack1 ! +--Class1.java ! +--Class2.java +--team2 +--com +--example +--pack2 +--ClassA.java +--ClassB.java But all packages should be compiled into a common directory like this: build +--com +--example +--pack1 ! +--Class1.class ! +--Class2.class +--pack2 +--ClassA.class +--ClassB.class The following task would compile all sources: javac srcdir=src destdir=build /javac But it would not be able to track unchanged *.java-files and does a recompile each time ant is invoked. Todays solution is either calling javac twice or copying all *.java-files to a common directory before calling javac. I guess it's faster and easier just to tell javac, how to find matching sources and output like this: javac srcdir=src destdir=build mapper type=regexp from=[^/]+/(.*)\.java to=\1.class/ /javac Of course mapper type=glob from*.java to=*.class/ will be the default. Do you think this makes sense? Ulf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javac-task and mapper
On Sat, 16 Aug 2003, Ulf Caspers [EMAIL PROTECTED] wrote: My question is: Are there any concerns about a mapper element in a java task? java or javac? What would the mapper in javac be supposed to do? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
