DO NOT REPLY [Bug 23889] - preservelastmodified for javac task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23889>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23889 preservelastmodified for javac task [EMAIL PROTECTED] changed: What|Removed |Added Version|1.6Beta |1.6.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24411] - odd presetdef behavior with "additive" task parameters like javac srcdir
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24411>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24411 odd presetdef behavior with "additive" task parameters like javac srcdir [EMAIL PROTECTED] changed: What|Removed |Added Version|1.6Beta |1.6.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24411] - odd presetdef behavior with "additive" task parameters like javac srcdir
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24411>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24411 odd presetdef behavior with "additive" task parameters like javac srcdir [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-11-06 09:09 --- Ok committed the changes, this should be available in the next ant beta build - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24411] - odd presetdef behavior with "additive" task parameters like javac srcdir
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24411>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24411 odd presetdef behavior with "additive" task parameters like javac srcdir --- Additional Comments From [EMAIL PROTECTED] 2003-11-05 14:57 --- I made a patch to preset to correct the odd behaviour It involves changes to a number of core ant classes (UnknownElement, IntrospectionHelper and RuntimeConfigurable) and the code is a little 'hacky', so I have just made it a patch at the moment. The patch will make attributes and text of the predefined task optional, in that they can be overriden by the user *without* the target class being aware of the override. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24411] - odd presetdef behavior with "additive" task parameters like javac srcdir
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24411>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24411 odd presetdef behavior with "additive" task parameters like javac srcdir --- Additional Comments From [EMAIL PROTECTED] 2003-11-05 14:48 --- Created an attachment (id=8945) Patch to modify behaviour of presetdef - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24411] New: - odd presetdef behavior with "additive" task parameters like javac srcdir
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24411>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24411 odd presetdef behavior with "additive" task parameters like javac srcdir Summary: odd presetdef behavior with "additive" task parameters like javac srcdir Product: Ant Version: 1.6Beta Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If you use presetdef to create a new task definition, and you supply a default value to a "cumulative" parameter like javac's "srcdir", users of that new definition cannot override that default value, they can only add to it. I find this behavior surprising, and I feel that it seriously limits the usefulness of "presetdef". Many tasks have cumulative parameters like this, e.g.: javac: srcdir, *classpath, extdirs, ... javadoc: sourcepath, packagenames, ... jar: includes, excludes, ... I suspect that users of presetdef will find it much more useful if default values of these cumulative parameters can be overridden, not just supplemented. BTW, aside from this nit, "presetdef" is a wonderful addition to Ant. THanks! The following build file illustrates the problem = CUT HERE - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ant javac task fails with kaffe + build.compiler=extJavac
Juan Antonio Martinez wrote: Environment: Linux RedHat 9 kaffe-1.1.2 ant-1.5.4 Take a look at this item: . When using compiler="kjc" works fine, but if change to compiler="extJavac" I get these errors: [javac] Compiling 2 source files to /home/jantonio/public_html/work/test/build [javac] Kjc: invalid option -- : Attached comes output on "ant -v -debug" Talking with kaffe people they suggested me that perhaps "compiler=extJavac" behaviour should try to detect which compiler is to be used and adjust invoice parametters according it I dont think this is a valid defect. from the docs: kjc (the kopi compiler). extJavac (run either modern or classic in a JVM of its own). extJava is simply meant to be the normal compiler in a new JVM, not an arbitrary compiler. Why not stick to using kjc if that is what you want. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ant javac task fails with kaffe + build.compiler=extJavac
On Fri, 31 Oct 2003, Juan Antonio Martinez <[EMAIL PROTECTED]> wrote: > [javac] Kjc: invalid option -- : > > Attached comes output on "ant -v -debug" Well, wherever the -- comes from, it is not from Ant (as your debug trace shows). What is /opt/usr/java/kaffe-1.1.2/bin/javac? A shell script passing things up to Kjc? Maybe this one is adding/modifiying arguments? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ant javac task fails with kaffe + build.compiler=extJavac
Environment: Linux RedHat 9 kaffe-1.1.2 ant-1.5.4 Take a look at this item: . When using compiler="kjc" works fine, but if change to compiler="extJavac" I get these errors: [javac] Compiling 2 source files to /home/jantonio/public_html/work/test/build [javac] Kjc: invalid option -- : Attached comes output on "ant -v -debug" Talking with kaffe people they suggested me that perhaps "compiler=extJavac" behaviour should try to detect which compiler is to be used and adjust invoice parametters according it cheers -- Juan Antonio Martinez <[EMAIL PROTECTED]> Dpto Ingenieria Telematica report.gz Description: GNU Zip compressed data signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
DO NOT REPLY [Bug 23889] - preservelastmodified for javac task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23889>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23889 preservelastmodified for javac task [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-10-22 22:33 --- two issues here (a) compilation is done by various tools -like javac- that even add in new files to compile if they are imported. So ant doesnt even know all the files that will be compiled. (b) I have trouble thinking of valid use cases. It is too dangerous to do this, as suddenly dependencies dont get picked up. And it wont work the way you want, as inter-class dependencies complicate the game. If your compiler is slow, get jikes, from jikes.org. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23889] New: - preservelastmodified for javac task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23889>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23889 preservelastmodified for javac task Summary: preservelastmodified for javac task Product: Ant Version: 1.6Beta Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hello everybody, I'd like to see a "preservelastmodified" option for the "javac" task (similar to "preservelastmodified" in "copy"). The current situation is that, if I delete an output file (.class) and invoke "javac" once more, the new .class file has got the current date and is detected as new by all following tasks. Regards, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17512] - Quitting javac task with CTRL-C can leave temporary files
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17512>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17512 Quitting javac task with CTRL-C can leave temporary files [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |1.6 Version|1.7Alpha (nightly) |1.5.4 --- Additional Comments From [EMAIL PROTECTED] 2003-10-14 13:23 --- I've tried to hunt down all temporary files that we create and marked them as deleteOnExit (without reflection as Ant 1.6 drops the 1.1 dependency). My reading of this method's Javadocs is that you are lucky if this happens to remove the temporary files when you hit ^C (Deletion will be attempted only for normal termination of the virtual machine). Fixed in CVS HEAD and Ant 1.6beta2. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23508] - JAVAC ignores excludes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23508>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23508 JAVAC ignores excludes [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23508] - JAVAC ignores excludes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23508>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23508 JAVAC ignores excludes --- Additional Comments From [EMAIL PROTECTED] 2003-09-30 09:37 --- does any of the classes you compile depend on com.mypackage.MyClass? If so, javac (the compiler, not Ant) may pick it up by itself. To avoid that, set the sourcepath attribute to an empty string. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23508] New: - JAVAC ignores excludes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23508>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23508 JAVAC ignores excludes Summary: JAVAC ignores excludes Product: Ant Version: 1.4.1 Platform: Sun OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When adding the excludes attribute to javac ant-task it is ignored, despite using the syntax explained in the manual, i.e. the file(s) in excludes are compiled anyway. E.g. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23401] - javac fails with fork=true and spaces in the source directory name
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23401>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23401 javac fails with fork=true and spaces in the source directory name [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE Target Milestone|--- |1.6 --- Additional Comments From [EMAIL PROTECTED] 2003-09-25 09:37 --- Supposed to be fixed in Ant's CVS HEAD (and the soon to be released 1.6beta). *** This bug has been marked as a duplicate of 10499 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23401] New: - javac fails with fork=true and spaces in the source directory name
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23401>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23401 javac fails with fork=true and spaces in the source directory name Summary: javac fails with fork=true and spaces in the source directory name Product: Ant Version: 1.5.3 Platform: PC URL: http://jira.codehaus.org/secure/ViewIssue.jspa?id=11616 OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] See above URL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20202] - javac deprecation tag doesn't show deprecation's
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20202>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20202 javac deprecation tag doesn't show deprecation's --- Additional Comments From [EMAIL PROTECTED] 2003-09-12 09:51 --- Created an attachment (id=8183) Zipped example - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20202] - javac deprecation tag doesn't show deprecation's
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20202>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20202 javac deprecation tag doesn't show deprecation's [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-09-12 09:49 --- Deprecation warnings only show up if the class with the deprecated method is not itself being compiled. If the class is included in the file sbeing compiled, no warning is given by the javac compiler. I will attach a little example of a deprecated method call. If it is compiled in two steps, the warnign is given but if it is compiled in one go, no warning is given. The following is what happens on my system: $ ant compile2 Buildfile: build.xml compile1: [mkdir] Created dir: /home/conor/development/apache/ant-bugs/20202/classes [javac] Compiling 1 source file to /home/conor/development/apache/ant-bugs/20202/classes compile2: [javac] Compiling 1 source file to /home/conor/development/apache/ant-bugs/20202/classes [javac] /home/conor/development/apache/ant-bugs/20202/src2/Test2.java:5: warning: testDep() in Test has been deprecated [javac] instance.testDep(); [javac] ^ [javac] 1 warning BUILD SUCCESSFUL and $ ant compileAll Buildfile: build.xml compileAll: [mkdir] Created dir: /home/conor/development/apache/ant-bugs/20202/classesAll [javac] Compiling 2 source files to /home/conor/development/apache/ant-bugs/20202/classesAll BUILD SUCCESSFUL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23035] - javac always recompiles when multiple src paths are given
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23035>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23035 javac always recompiles when multiple src paths are given --- Additional Comments From [EMAIL PROTECTED] 2003-09-10 18:36 --- Search for a recent thread/bug where one can specify sourcepath="" exlicitly (to empty) to avoid having Javac find dependent classes not explicitly in the fileset (excluded for example). Hope this helps. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23035] - javac always recompiles when multiple src paths are given
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23035>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23035 javac always recompiles when multiple src paths are given [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-09-10 18:19 --- A part of the behavior of javac is not under the control of ant. javac notices probably that ClassA has changed and compiles it. If you want to compile against a frozen status of a package, then you need to make a jar file or a set of .class files with this package, and remove the sources of this package from what javac is given to see. I am closing this bug report as invalid, since this is not an ant issue. Cheers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23035] - javac always recompiles when multiple src paths are given
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23035>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23035 javac always recompiles when multiple src paths are given --- Additional Comments From [EMAIL PROTECTED] 2003-09-10 18:05 --- You mean like this whereas the include would be optional. The output is: compile: [javac] Compiling 1 source file to D:\projects\antTest\target\classes Which looks ok and as I would expect it. But infact it compiles 2 sources. packone.ClassA is implicitly compiled, although I excluded it. I think, this is because of the dependency: public class ClassB extends ClassA I'm running into this, because I want ClassB to use myjar.jar/packone/ClassA and not recompile it from the source tree. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23035] - javac always recompiles when multiple src paths are given
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23035>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23035
javac always recompiles when multiple src paths are given
--- Additional Comments From [EMAIL PROTECTED] 2003-09-10 17:45 ---
it sounds like you should not use several src paths but rather
except if your package hierarchy starts at ${srcdir}/packone and
${srcdir}/packtwo ?
when your package names start with com, then the paths of the src nested
elements should point to the source directories containing com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23035] - javac always recompiles when multiple src paths are given
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23035>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23035 javac always recompiles when multiple src paths are given --- Additional Comments From [EMAIL PROTECTED] 2003-09-10 17:09 --- Yes, packone and packtwo are package names. Say ClassA lives in packone and ClassB in packtwo. ClassB extends ClassA. I want to exlude packone and only compile packtwo. I expect an ClassNotFoundException on ClassA, but javac implicitly compiles ClassA although I excluded it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23035] - javac always recompiles when multiple src paths are given
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23035>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23035 javac always recompiles when multiple src paths are given --- Additional Comments From [EMAIL PROTECTED] 2003-09-10 16:57 --- this bug is similar to http://issues.apache.org/bugzilla/show_bug.cgi?id=3198 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23035] - javac always recompiles when multiple src paths are given
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23035>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23035 javac always recompiles when multiple src paths are given --- Additional Comments From [EMAIL PROTECTED] 2003-09-09 17:05 --- If packone, and packtwo are part of the package names, then it's not a bug, but a misuse of . --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23035] New: - javac always recompiles when multiple src paths are given
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23035>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23035 javac always recompiles when multiple src paths are given Summary: javac always recompiles when multiple src paths are given Product: Ant Version: 1.5.4 Platform: PC OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] With this it always recompiles all sources. My project contains 1200 files, which then is a problem. Is there a solution? Thanks thomas - 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? > > > > > > > > > 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: trying to get access to fileset from new task to javac task
Dean,
vppjavac (vpp.sourceforge.net, source available) wraps javac too perform
file preprocessing on the source path before invoking javac. The intent was
that vppjavac be a 'drop-in' replacement for javac. Originally, I'd hope to
simply extend Javac, however, because of the protected visibility of the src
fileset, I had to additionally create a new instance of Javac and execute it
in vppjavac's execute() method. So, my solution was to both extend and
create a new instance. I figure the extension still has value since it
guarantees that vppjavac's public interface is still a superset of javac's.
Here is how I invoke Javac internally, you could probabaly just cut & paste
this and fix the srcdir property how you want:
// Since the source path can't be reset directly, we have to create
a
// new Javac...
Javac javac = new Javac();
// --> set this how you want <--
javac.setSrcdir(somePath);
// ant properties
javac.setOwningTarget(getOwningTarget());
javac.setNowarn(javac.getNowarn());
javac.setFailonerror(getFailonerror());
javac.setLocation(getLocation());
javac.setTaskName(getTaskName());
// javac properties
javac.setDestdir(getDestdir());
javac.setEncoding(getEncoding());
javac.setDebug(getDebug());
javac.setOptimize(getOptimize());
javac.setDeprecation(getDeprecation());
javac.setDepend(getDepend());
javac.setVerbose(getVerbose());
javac.setTarget(getTarget());
javac.setBootclasspath(getBootclasspath());
javac.setExtdirs(getExtdirs());
javac.setClasspath(getClasspath());
javac.setProject(getProject());
javac.setLocation(getLocation());
javac.setIncludeantruntime(getIncludeantruntime());
javac.setIncludejavaruntime(getIncludejavaruntime());
javac.setMemoryInitialSize(getMemoryInitialSize());
javac.setMemoryMaximumSize(getMemoryMaximumSize());
// Compile!!
javac.execute();
Why should the src fileset be immutable when not much else is, particularly
classpath? No clue, maybe someone can shed some light on this...
didge
> -Original Message-
> From: Dean Hiller [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 25, 2003 6:25 AM
> To: Ant Developers List
> Subject: Re: trying to get access to fileset from new task to javac task
>
>
> I am compiling the same src directory every time, but with different
> patterns.
>
> Javac uses the FileSet in MatchingTask. I currently have a hack into
> MatchingTask adding
> public void putNewFileSet(FileSet set) {
> fileset = set;
> }
> because I am not sure how to change out the FileSet of patterns. Above
> works for me, but is there an easier way ***without changing the ant
> base*** to get what I want.
>
> Your last statement is exactly my intention.
> thanks,
> dean
>
>
>
> Stefan Bodewig wrote:
>
> >On Sun, 24 Aug 2003, Dean Hiller <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >>I am writing a new task that happens to wrap javac and call it a few
> >>times. Is there any way to clear the FileSet?
> >>
> >>
> >
> >javac doesn't use a FileSet at all, or it uses a fresh FileSet for all
> > and srcdir entries - depends on how you look at it.
> >
> >
> >
> >>Short story is I want to reuse the same javac with all the same
> >>parameters compiling a different fileset each time.
> >>
> >>
> >
> >Compiling a different src directory?
> >
> >
> >
> >>Maybe it would be ok to put a public clearFileSet in
> >>MatchingTask.java???
> >>
> >>
> >
> >That would only affect the include/exclude patterns but nothing else.
> >
> >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: trying to get access to fileset from new task to javac task
I am compiling the same src directory every time, but with different
patterns.
Javac uses the FileSet in MatchingTask. I currently have a hack into
MatchingTask adding
public void putNewFileSet(FileSet set) {
fileset = set;
}
because I am not sure how to change out the FileSet of patterns. Above
works for me, but is there an easier way ***without changing the ant
base*** to get what I want.
Your last statement is exactly my intention.
thanks,
dean
Stefan Bodewig wrote:
On Sun, 24 Aug 2003, Dean Hiller <[EMAIL PROTECTED]> wrote:
I am writing a new task that happens to wrap javac and call it a few
times. Is there any way to clear the FileSet?
javac doesn't use a FileSet at all, or it uses a fresh FileSet for all
and srcdir entries - depends on how you look at it.
Short story is I want to reuse the same javac with all the same
parameters compiling a different fileset each time.
Compiling a different src directory?
Maybe it would be ok to put a public clearFileSet in
MatchingTask.java???
That would only affect the include/exclude patterns but nothing else.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: trying to get access to fileset from new task to javac task
On Sun, 24 Aug 2003, Dean Hiller <[EMAIL PROTECTED]> wrote: > I am writing a new task that happens to wrap javac and call it a few > times. Is there any way to clear the FileSet? javac doesn't use a FileSet at all, or it uses a fresh FileSet for all and srcdir entries - depends on how you look at it. > Short story is I want to reuse the same javac with all the same > parameters compiling a different fileset each time. Compiling a different src directory? > Maybe it would be ok to put a public clearFileSet in > MatchingTask.java??? That would only affect the include/exclude patterns but nothing else. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
trying to get access to fileset from new task to javac task
I am writing a new task that happens to wrap javac and call it a few times. Is there any way to clear the FileSet? or possibly retrieve the FileSet from Javac's superclass(MatchingTask)? The getImplicitFileset() was protected and there doesn't seem to be a clear function on the MatchingTask to clear the FileSet. Couldn't find anything in Javac either. Is there a way to clone Javac that I am not aware of??? Short story is I want to reuse the same javac with all the same parameters compiling a different fileset each time. Maybe it would be ok to put a public clearFileSet in MatchingTask.java??? I do plan on submitting my ant task back into ant when done. thanks for any advice on this, dean - 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? > > > > > > > > > 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
> 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:
And here is an clip from one of my project build.xml files showing the
'init' and XML include:
]>
&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 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 and mapper
> >
> > How about this?
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > didge
> >
> > > -Original Message-
> > > From: Ulf Caspers [mailto:[EMAIL PROTECTED]
> > > Sent: Tuesday, August 19, 2003 11:06 AM
> > > To: [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? > > > > > > > > > > > > > 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: > > > > > > > > > > > > > > > > > > > > > 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 > > "team"s. > > > > 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
How about this? 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: > > > > > > > > > > > > > > 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 > "team"s. > > 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] > > - 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: > > > > > > > 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 "team"s. 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
All you need to do is: 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: > > > or ? > ! > > > What would the mapper in 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: > > destdir="build"> > > > 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: > > destdir="build"> > > > > Of course 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 Mon, 18 Aug 2003, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > or ? ! > What would the mapper in 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: 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: Of course 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? or ? What would the mapper in be supposed to do? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
javac-task and mapper
Hello, on 2002-02-09 there was a suggestion by Vadim Zaliva to add the mapper element to the javac task. I'm quite new to ant but I searched through the mailinglist archives and could not find a reason for not following his solution. My question is: Are there any concerns about a mapper element in a java task? If not, I volunteer to write a patch including all necessary documentation updates (with an example) and maybe even a testcase. Ulf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22427] - javac task to compile files independently
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22427>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22427 javac task to compile files independently --- Additional Comments From [EMAIL PROTECTED] 2003-08-15 08:57 --- Created an attachment (id=7831) Patch to the documentation to mention this feature - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5268] - Should allow execution of javac with no sourcepath set
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5268>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5268 Should allow execution of javac with no sourcepath set [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 16:03 --- *** Bug 22427 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22427] - javac task to compile files independently
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22427>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22427 javac task to compile files independently [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE Target Milestone|--- |1.5.2 Version|1.5.3 |1.4.1 --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 16:03 --- should do (Thu Feb 14 17:34:19 2002 UTC ;-) *** This bug has been marked as a duplicate of 5268 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22427] - javac task to compile files independently
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22427>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22427 javac task to compile files independently --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 15:54 --- Whaooo, I *strongly* support this request!!! I never realized one could actually *not* specify the sourcepath. I developped a complex XSL based system to compile groups of files in a single src/ directory to keep circular dependencies between the groups in check, and could completely scrap it and replace it with simple s would this enhancement make it thru. This ability to compile only a subset of files from a source tree without Javac automatically finding the dependent source files in the same tree would be tremendously useful IMHO!!! --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22427] New: - javac task to compile files independently
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22427>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22427 javac task to compile files independently Summary: javac task to compile files independently Product: Ant Version: 1.5.3 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Problem description: I have a lot of .java files in src/ directory and they form a logical groups which I would like to compile separately. Of course I could move the files into group1/src, group2/src, but that would mean that I loose CVS history of each file (we have horrible relation with our CVS server maintainer). That is why I decided to convince javac to compile the files separatelly even the sources share the same root. Surprisingly it is possible - one just does not specify -sourcepath, only names all the files to compile with full name and javac does not try to search for files not explicitly enumerated as arguments. I have tried to do the same with Ant task, but it seems there is no way to *not* specify the sourcepath and just enumerate the files (I understand, there would be no way to check whether the files are already compiled or not). Let say that I would like to do something like this: and be sure that if by a chance file in group2 references file in group1 that the second compilation fails. Request: I would like the task to allow compilation without specifying the sourcepath. Then the above described behaviour of javac could be used and my separation could work. Workaround: Actually there is a workaround of this problem. But it relies on the "srcdirnote": http://ant.apache.org/manual/CoreTasks/javac.html#srcdirnote and I am affraid it could be broken with future version of ant. The trick is based on specification of wrong sourcepath (src/org instead of src) and then moving the compiled classes at right location. See it at: http://www.netbeans.org/source/browse/openide/build.xml.diff?r1=1.148.4.16&r2=1.148.4.17 I would be glad if we could remove this hack in some version of ant with improved . Regards. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DOCPATCH] javac task doc
The default for verbose is off. Let's mention that in the docs. :) (Sorry if my mailer wraps this, sometimes attachments don't make it through, but the patch should be pretty straight forward as what to do). -- Larry Index: docs/manual/CoreTasks/javac.html === RCS file: /home/cvspublic/ant/docs/manual/CoreTasks/javac.html,v retrieving revision 1.40 diff -u -r1.40 javac.html --- docs/manual/CoreTasks/javac.html15 May 2003 12:44:00 - 1.40 +++ docs/manual/CoreTasks/javac.html12 Aug 2003 17:37:29 - @@ -243,7 +243,7 @@ verbose -Asks the compiler for verbose output. +Asks the compiler for verbose output; defaults to off. No - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18055] - javac task includes java rt.jar in classpath when using jvc compiler
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18055>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18055 javac task includes java rt.jar in classpath when using jvc compiler [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED Target Milestone|1.5.3 |1.6 --- Additional Comments From [EMAIL PROTECTED] 2003-08-08 14:36 --- I have taken out the extdirs for jvc when includejavaruntime is false. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18055] - javac task includes java rt.jar in classpath when using jvc compiler
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18055>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18055 javac task includes java rt.jar in classpath when using jvc compiler [EMAIL PROTECTED] changed: What|Removed |Added Status|CLOSED |REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2003-08-06 23:33 --- I am running ant version 1.5.3(.1) and ant -debug shows my javac task (which is configured to use jvc) is still including the jre\lib\ext libraries despite having the includeJavaRuntime property set to "no". ant is setting the classpath as shown below: [javac] '/cp:p' [javac] 'C:\j2sdk1.4.2\jre\lib\ext\dnsns.jar;C:\j2sdk1.4.2\jre\lib\ext\ldaps ec.jar;C:\j2sdk1.4.2\jre\lib\ext\localedata.jar;C:\j2sdk1.4.2\jre\lib\ext\sunjce _provider.jar' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21868] - javac task fails if there are space in the Absolute Path of the srcdir
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21868>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21868 javac task fails if there are space in the Absolute Path of the srcdir [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE Target Milestone|--- |1.6 --- Additional Comments From [EMAIL PROTECTED] 2003-07-25 07:00 --- This bug is already known and fixed in CVS head. You can download a nightly build from http://cvs.apache.org/builds/ant/nightly *** This bug has been marked as a duplicate of 10499 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21868] New: - javac task fails if there are space in the Absolute Path of the srcdir
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21868>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21868 javac task fails if there are space in the Absolute Path of the srcdir Summary: javac task fails if there are space in the Absolute Path of the srcdir Product: Ant Version: 1.5.3 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] javac fails because the java compiler provided with the SDK does not handle spaces in path provided up to the Source File. While it is true that spaces are not valid for package names, the directory structure beneath the package directories can have spaces without consequences. If absolute paths are going to be fed to the java compiler by the javac task, then spaces should be escaped in a manner appropriate to the OS. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20202] - javac deprecation tag doesn't show deprecation's
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20202>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20202 javac deprecation tag doesn't show deprecation's --- Additional Comments From [EMAIL PROTECTED] 2003-07-21 23:25 --- with the deprecation flag on i just get the message [javac] 95 warnings The compiler warning messages and source code location should be shown - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21497] - javac succeeds when it should fail
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21497>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21497 javac succeeds when it should fail [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-07-11 11:45 --- doesn't do any dependency checking itself, this is out of scope for this task, we use for this (or look at on the external tools page). Because of this, Ant would only try to recompile Bottom - which should still fail unless it is included from the compilation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21497] New: - javac succeeds when it should fail
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21497>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21497 javac succeeds when it should fail Summary: javac succeeds when it should fail Product: Ant Version: 1.5.2 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This behaviour is observed: 1. Run Ant, and javac fails due to a bug in the source code being compiled. Fair enough. 2. Run Ant again and it appears to succeed even though the buggy class was not compiled (so the software will not work). The particular problem is that if you tell the Ant javac task to compile a class Top which imports Middle, which in turn imports Bottom, and Bottom has compile time errors that do not affect its method signature, then Top and Middle will be built successfully but Bottom will not be. On a subsequent run, the javac task only tries to build Top, which checks only Middle and so Bottom is never rebuilt. It looks as though bug 13409 could have been the same thing, but the reporter gave insufficent detail and the bug was marked as in valid. http://issues.apache.org/bugzilla/show_bug.cgi?id=13409 It's unlikely, but http://issues.apache.org/bugzilla/show_bug.cgi?id=14808 just might be related, since it's about javac being happy when an output file is missing. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21011] New: - Javac task's behaviour ignores
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21011>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21011 Javac task's behaviour ignores Summary: Javac task's behaviour ignores Product: Ant Version: 1.5.3 Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Ant's different behaviour from the standard javac concerning the default debug level has been well documented in bug#1011 and bug#5167. However setting debugging to '-g:none' when == false is causing me some different problem. I'm using the parameter to set (amongst others) the debug level for my compile targets. However setting the '-g' option is ignored because ant already implicitly put '-g:none' on the commandline. This is causing me some inconvience not only because it deviates from the default behaviour of javac but because it prevents me from setting the debug level using a valid ant command - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FileSet reference in Javac ..
On Fri, 20 Jun 2003 02:59 am, Harsha Kalidindi wrote: > Hi: > > I looked through the mail archives to see if anyone had the same > issue with not being able to reference FileSets in Javac. I saw a query but > no responses. > > > >... > > > Why is that above not allowed? Do I have to extend javac if I want > the above behavior? > Currently really uses patternsets rather than filesets. The and patterns from the implicit fileset are used with all source base directories to get the set of Java files to compile. In effect the and are filtering based on Java package name (expressed in the file system equivalent way). I think it would be possible to support filesets directly - just nobody has done it to date. I think to work in with the right way, the fileset basedir would need to be the package root. There would be some work to do to make sure that the fileset basedirs were added to the list of source dirs, etc. Definitely possible. Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FileSet reference in Javac ..
Hi: I looked through the mail archives to see if anyone had the same issue with not being able to reference FileSets in Javac. I saw a query but no responses. ... Why is that above not allowed? Do I have to extend javac if I want the above behavior? Thanks, Harsha [EMAIL PROTECTED] 212.762.4165 This communication is intended for the addressee(s) and may contain confidential and legally privileged information. We do not waive confidentiality or privilege by mis-transmission. If you have received this communication in error, any use, dissemination, printing or copying is strictly prohibited; please destroy all electronic and paper copies and notify the sender immediately.
DO NOT REPLY [Bug 18053] - Incorrect javac task documentation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18053>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18053 Incorrect javac task documentation [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2003-06-17 00:17 --- Happy with the resolution in the latest release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17683] - javac task fails if path for java file contains space and if using external compiler
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17683>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17683
javac task fails if path for java file contains space and if using external
compiler
--- Additional Comments From [EMAIL PROTECTED] 2003-06-03 22:03 ---
Anne, I believe I have solved this bug together with the bug 10499.
However, I did not put this
if ( i==0)
{
out.println(args[i]);
}
in CVS, because I did not know why you had put this line.
Maybe the command line arguments used to be in args[0], so you did not want to
see them quoted. My understanding is that in ant1.6alpha, only filenames are in
this array, so my fix will be fine.
Let me know if I am wrong.
DO NOT REPLY [Bug 20408] - Allow passing arguments to javac globally
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20408>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20408 Allow passing arguments to javac globally --- Additional Comments From [EMAIL PROTECTED] 2003-06-02 09:06 --- Created an attachment (id=6594) Compiler Adapter
DO NOT REPLY [Bug 20408] New: - Allow passing arguments to javac globally
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20408>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20408 Allow passing arguments to javac globally Summary: Allow passing arguments to javac globally Product: Ant Version: 1.5.3 Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I wanted to compile my project with non-standard javac options. The simplest way, I found, was to create a CompilerAdapter. Usage is simple: ant -Dbuild.compiler=org.netbeans.nbbuild.NbJavacExternal -Dbuild.compiler.params=-param1,-param2 If you find my adapter useful, feel free to add it to CVS.
DO NOT REPLY [Bug 20202] - javac deprecation tag doesn't show deprecation's
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20202>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20202 javac deprecation tag doesn't show deprecation's --- Additional Comments From [EMAIL PROTECTED] 2003-05-30 08:01 --- ant -verbose should also show you whether -deprecation gets passed to the compiler. Does it? In my experience you'll always get deprecation warnings, they just get more detailed when you turn on -deprecation, so if you are not getting warnings at all that is strange. Reasons I could see: * your files are not getting compiled at all - you say this doesn't happen * your files get compiled against a version of the classes they depend upon where the method hasn't been deprecated. Any older version of said classes in your CLASSPATH or or ? No other ideas, sorry.
DO NOT REPLY [Bug 20202] - javac deprecation tag doesn't show deprecation's
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20202>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20202 javac deprecation tag doesn't show deprecation's --- Additional Comments From [EMAIL PROTECTED] 2003-05-27 14:37 --- yeah, the files get compiled. and correctly. they just don't show depercation warnings.
DO NOT REPLY [Bug 20202] - javac deprecation tag doesn't show deprecation's
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20202>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20202 javac deprecation tag doesn't show deprecation's --- Additional Comments From [EMAIL PROTECTED] 2003-05-27 07:35 --- Are you sure the file that calls the deprecated method gets compiled at all? See ant -verbose for a listing of all files that get compiled.
DO NOT REPLY [Bug 20202] New: - javac deprecation tag doesn't show deprecation's
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20202>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20202 javac deprecation tag doesn't show deprecation's Summary: javac deprecation tag doesn't show deprecation's Product: Ant Version: 1.5.3 Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] i belive if i am calling a deprecated function, it should show up when making this call. nothing does. just says build successful.
DO NOT REPLY [Bug 11143] - Javac should load build.compiler class from a defined classloader
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11143>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11143 Javac should load build.compiler class from a defined classloader [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
DO NOT REPLY [Bug 19285] - Invalid path when using javac with fork="true"
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19285>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19285 Invalid path when using javac with fork="true" [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-04-28 10:15 --- OK, I think the spaces in the filenames inside the parameter file are the problem. *** This bug has been marked as a duplicate of 10499 ***
DO NOT REPLY [Bug 19285] - Invalid path when using javac with fork="true"
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19285>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19285 Invalid path when using javac with fork="true" --- Additional Comments From [EMAIL PROTECTED] 2003-04-25 09:38 --- Created an attachment (id=6007) ant -debug output for javac
DO NOT REPLY [Bug 19285] - Invalid path when using javac with fork="true"
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19285>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19285 Invalid path when using javac with fork="true" --- Additional Comments From [EMAIL PROTECTED] 2003-04-25 06:41 --- Could you give us a complete output (of the javac task, you can snip the rest) from ant -debug please?
DO NOT REPLY [Bug 19285] - Invalid path when using javac with fork="true"
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19285>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19285 Invalid path when using javac with fork="true" --- Additional Comments From [EMAIL PROTECTED] 2003-04-24 19:48 --- Same problem with nested .
DO NOT REPLY [Bug 19285] - Invalid path when using javac with fork="true"
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19285>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19285 Invalid path when using javac with fork="true" --- Additional Comments From [EMAIL PROTECTED] 2003-04-24 19:35 --- Sounds like a bug... Could you try with a nested instead of 'srcdir', just in case. Thanks, --DD
DO NOT REPLY [Bug 19285] New: - Invalid path when using javac with fork="true"
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19285>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19285 Invalid path when using javac with fork="true" Summary: Invalid path when using javac with fork="true" Product: Ant Version: 1.5.3 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The javac task fails if the (expanded) srcdir contains one or more spaces, but only if fork is set to true. [javac] Compiling 256 source files to C:\Documents and Settings\Eric\My Docu ments\Projects\Test\build [javac] javac: invalid flag: C:\Documents [javac] Usage: javac ...
DO NOT REPLY [Bug 17512] - Quitting javac task with CTRL-C can leave temporary files
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17512>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17512 Quitting javac task with CTRL-C can leave temporary files [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED
DO NOT REPLY [Bug 18950] - Enable Javac to update jar file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18950>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18950 Enable Javac to update jar file --- Additional Comments From [EMAIL PROTECTED] 2003-04-12 17:59 --- Point taken - but one doesn't have to use the feature if it causes problems. I was thinking of projects such as JMeter, where the output jars (apart from jorphan) are not on the classpath.
DO NOT REPLY [Bug 18950] - Enable Javac to update jar file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18950>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18950 Enable Javac to update jar file --- Additional Comments From [EMAIL PROTECTED] 2003-04-11 13:29 --- If the jar is on the classpath (and it is probably going to end up there, at least for ), you won't be able to alter its content on Windows - it will be locked. If you manage to change the jar (on Unix systems for example) you run a good chance of destroying the stability of your VM. Many VMs scan the CLASSPATH upfront and get really confused if an archive changes during their lifetime.
DO NOT REPLY [Bug 18950] New: - Enable Javac to update jar file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18950>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18950 Enable Javac to update jar file Summary: Enable Javac to update jar file Product: Ant Version: 1.5.3 Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] It would be useful to be able to specify a jar file which was to be updated with any new class files created. This might speed up incremental builds. [[Might be tricky to work out the names of nested class files. One way might be to parse the -verbose output; another might be to write the class files into a temporary directory first.]] If the target jar file did not exist, then the update command should probably be ignored, as the build is probably a full build.
DO NOT REPLY [Bug 13409] - javac fails on first compilation and succeds on second
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13409>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13409 javac fails on first compilation and succeds on second [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID
DO NOT REPLY [Bug 4230] - [javac] jikes 1.14 does not support -encoding
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4230>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4230 [javac] jikes 1.14 does not support -encoding [EMAIL PROTECTED] changed: What|Removed |Added CC||apache- ||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-03-25 16:26 --- *** Bug 18322 has been marked as a duplicate of this bug. ***
DO NOT REPLY [Bug 18055] - javac task includes java rt.jar in classpath when using jvc compiler
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18055>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18055 javac task includes java rt.jar in classpath when using jvc compiler [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2003-03-20 21:53 --- Shouldn't you make it clear whether you support running Ant with a Microsoft VM or not? Its no use have code for something that you think might work, but may indeed not work. Either it should be supported and work, or not supported. Anyway it's not a big issue since I don't use the Microsoft VM. Yes I realised the docs for the includeJavaRuntime attribute were wrong, I logged that too ;) Anyway, I'm closing this as I am satisfied with the resolution.
DO NOT REPLY [Bug 18055] - javac task includes java rt.jar in classpath when using jvc compiler
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18055>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18055 javac task includes java rt.jar in classpath when using jvc compiler [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.5.3 --- Additional Comments From [EMAIL PROTECTED] 2003-03-20 09:13 --- OK, fixed, thanks for the detailed analysis.
DO NOT REPLY [Bug 18055] - javac task includes java rt.jar in classpath when using jvc compiler
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18055>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18055 javac task includes java rt.jar in classpath when using jvc compiler --- Additional Comments From [EMAIL PROTECTED] 2003-03-20 08:55 --- About the Microsoft VM - I have no idea, I've never tried to run Ant on a Microsoft OS, much less a Microsoft VM 8-) Ant 1.5.x is supposed to work on Java 1.1 compatible VMs, so it might work. I'll take care of the implicitly re-setting includeJavaRuntime. BTW, false is the default for the attribute, the docs in 1.5.2 (and earlier) have been wrong.
DO NOT REPLY [Bug 18055] - javac task includes java rt.jar in classpath when using jvc compiler
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18055>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18055 javac task includes java rt.jar in classpath when using jvc compiler --- Additional Comments From [EMAIL PROTECTED] 2003-03-19 22:26 --- From http://ant.apache.org/manual/index.html: "Note: The Microsoft JVM/JDK is not adequate on its own, although the MS compiler is supported." The comment is a bit vague, but I take it to mean that running Ant with a Microsoft VM is not supported. (Correct me if I am wrong.) If this is the case, then why is does Ant have code that is only going to be used if running in a Microsoft VM? Otherwise if you do actually support running in the Microsoft VM, yes, the user should be given the choice of what to set includeJavaRuntime to. But if we are compiling with jvc from Ant running in the Sun VM, the Java runtime should never be included, as including Sun's Java runtime when compiling with Microsoft's compiler is always wrong. I would argue Ant should be smart enough to work this stuff out. Finally, (and I overlooked this in my original report), we have explicitly set includeJavaRuntime to false, but kept having problems. Having another look into org.apache.tools.ant.taskdefs.compilers.JVC reveals includeJavaRuntime is set to true if I don't specify a bootclasspath. So I can get things working by setting includeJavaRuntime to false, and include a nonsense bootclasspath so includeJavaRuntime is not set to true when running Ant using Sun's VM. I am happy to set includeJavaRuntime to false, but I believe shouldn't have to include a nonsense bootclasspath for this to work.
DO NOT REPLY [Bug 18055] - javac task includes java rt.jar in classpath when using jvc compiler
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18055>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18055 javac task includes java rt.jar in classpath when using jvc compiler --- Additional Comments From [EMAIL PROTECTED] 2003-03-19 10:24 --- The codesnippet actually is for the case where you are running Ant in a VM by Microsoft, not necessarily for running jvc. I'm not sure that you will always want to set includeJavaRuntime to false when running jvc and would prefer to leave that decision to the user explicitly. What is wrong with setting the attribute to false in your build files?
DO NOT REPLY [Bug 18053] - Incorrect javac task documentation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18053>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18053 Incorrect javac task documentation [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.5.3 --- Additional Comments From [EMAIL PROTECTED] 2003-03-19 08:28 --- patched, thanks.
DO NOT REPLY [Bug 18055] New: - javac task includes java rt.jar in classpath when using jvc compiler
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18055>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18055
javac task includes java rt.jar in classpath when using jvc compiler
Summary: javac task includes java rt.jar in classpath when using
jvc compiler
Product: Ant
Version: 1.5.2
Platform: All
OS/Version: All
Status: NEW
Severity: Major
Priority: Other
Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
When using Microsoft's jvc compiler for the javac task, rt.jar from the Java
install running Ant gets included in the compilation classpath. This is a
problem since code meant to be compiled with jvc is linked against Sun class
libraries which leads to compilation errors.
Delving into the addJavaRuntime() method in org.apache.ant.tools.types.Path
reveals the following statement intended to be called when using the jvc
compiler:
if
(System.getProperty("java.vendor").toLowerCase(Locale.US).indexOf("microsoft")
>= 0) {
...
}
The problem is this will never get called, as System.getProperty("java.vendor")
will return the vendor of the Java install being used to run Ant. Instead, the
method will (incorrectly) add the rt.jar of the Java install running Ant.
This can be fixed by altering includeJavaRuntime in
org.apache.tools.ant.taskdefs.compilers.JVC to always be false if no
bootclasspath has been supplied.
DO NOT REPLY [Bug 18053] New: - Incorrect javac task documentation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18053>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18053 Incorrect javac task documentation Summary: Incorrect javac task documentation Product: Ant Version: 1.5.2 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The documentation for javac says includeJavaRuntime defaults to yes. Looking at the source of org.apache.tools.ant.taskdefs.Javac reveals this is incorrect - it actually defaults to the opposite.
DO NOT REPLY [Bug 9199] - class compiles with javac but gives class not found errors in javadoc, with same classpath
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9199>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9199 class compiles with javac but gives class not found errors in javadoc, with same classpath [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-03-11 06:41 --- I agree, they are inconsistent. But this a quirk of history. came first. If we change it now, we break everything that depends on it. is part of the more strict model used in later systems. failonerror inconsistency is a similar problem...
DO NOT REPLY [Bug 17683] - javac task fails if path for java file contains space and if using external compiler
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17683>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17683 javac task fails if path for java file contains space and if using external compiler [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-03-10 09:31 --- *** This bug has been marked as a duplicate of 10499 ***
DO NOT REPLY [Bug 17683] New: - javac task fails if path for java file contains space and if using external compiler
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17683>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17683
javac task fails if path for java file contains space and if using external
compiler
Summary: javac task fails if path for java file contains space
and if using external compiler
Product: Ant
Version: 1.5
Platform: Other
OS/Version: Windows NT/2K
Status: NEW
Severity: Normal
Priority: Other
Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
If you try to compile java files which are in a directory containing a space
(for example in program files), you cannot fork the javac task.
I've worked around the problem by updating the following ant src file:
main/org/apache/tools/ant/taskdefs/compilers/DefaultCompilerAdapter.java
Changed the method executeExternalCompile(String[] args, int firstFileName) to
put quotes around the java file names.
So the following :
for (int i = firstFileName; i < args.length; i++) {
out.println(args[i]);
}
becomes
for (int i = firstFileName; i < args.length; i++) {
if ( i==0)
{
out.println(args[i]);
}
else
{
args[i] = args[i].replace('\\', '/');
out.println( "\"" + args[i] + "\"");
}
}
