Your ant\taskdefs\defaults.properties file must contain such line:
javac=org.apache.tools.ant.taskdefs.Javac.
May be this file doesn't copied to the dest directory properly.
Please ensure that you set ${src.path} directory properly to
the source path directory (./src).Vitaly > -----Original Message----- > From: Goldstein, Joel [mailto:[EMAIL PROTECTED] > Sent: Monday, June 12, 2000 7:56 PM > To: 'ant- ' > Subject: RE: javac dependencies > > > I built ant with this new Javac and created a jar file (all using ant's own > build.xml) > I now get the error when trying to run > "Could not create task of type: javac because I can't find it in the list of > task class definitions" > > Joel > > > -----Original Message----- > > From: Vitaly Stulsky [SMTP:[EMAIL PROTECTED] > > Sent: Thursday, June 08, 2000 7:38 AM > > To: [EMAIL PROTECTED] > > Subject: RE: javac dependencies > > > > > > Files: build.xml, build.xml.diff, java.java, lib.jar > > I didn't modify patch and also didn't check its compatibility with current > > version. > > Be careful while applying it! > > > > [Cut from the patch cover letter] > > At glance. > > ========== > > 1) Here is enclosed patch for the JavaC dependency tracking. > > 2) Also this patch allows using multiple source location in the JAVAC > > srcdir > > option. > > 3) Implemented new JAVAC option SOURCEPATH. > > > > Full description > > ================ > > 1) Dependency tracking. > > To switch on this feature you have to use dependence="on" JAVAC option. > > > > Algorithm performs class files analyzing and backward dependency > > tracking. > > Example: > > a) A.java depends on B.java. With applied patch if we change B.java, > > ANT > > automatically > > recompiles A.java. In current realization compile list contains only > > B.java. > > b) If we will change Task.java in the ant sources, current ant > > realization > > recompiles only one file. In new realization compile list contains >= > > 33 > > files > > (the number of files depends on your own Task extensions). > > > > For this functionality you have to modify manifest.mf. It is necessary > > to > > include > > lib.jar to the Class-path. > > > > In next few weeks I'll comment lib.jar source, make proper indentation > > and > > send sources to the community. Also it is possible to include lib.jar > > code > > to the ant.jar. If anybody wants to view the sources immediately I'll > > send > > them on first demand directly to he or she. > > > > 2) With applied patch it is possible to use such src dirs: > > <property name="src.dir" > > value= "com/company/progr/mainprogr; > > > > com/company/utils/protocol; > > > > com/company/utils/db; > > > > com/company/utils/diag; > > > > com/company/utils/html; > > > > com/company/utils/sort; > > > > com/company/utils/string; > > > > com/company/utils/thread; > > > > com/company/utils/test; > > > > com/company/utils/timer > > /> > > All paths must be separated by semicolon ( I estimate Unix users > > indignation, > > but now current > > approach easily extended to usage semicolon on NT platform and colon on > > Unix). > > > > 3) For every project it is necessary to specify sourcepath option. This > > option > > will be passed > > directly to javac. This functionality is follows from multiple src paths. > > Now > > you can > > specify not root of all packages in the srcdir option. Root dir has to be > > specified in > > sourcepath option. > > For our project this functionality is very useful, cause we have many > > reusable > > utilities and > > want to distribute parts of them with different projects. All utilities > > classes > > are stored > > in one upper-level package com.company.utils. For every project we have to > > select from 3 to 10 > > lower-level packages and include them to the distribution. Approach with > > multiple srcdirs makes > > build file easiest and better understandable. > > > > We'll be glad to answer all of your questions. > > > > [End cut] > > -------------------------------------------------------------------------- > > --------- > > Files: src.zip diffs.txt > > > > [Cut from Conor's patch cover letter] > > Interestingly I have also been working on dependency tracking and multiple > > source paths. > > > > For multiple source paths, I submitted a patch for multiple source paths a > > while back. I chose to use a comma to separate the source paths since it > > seemed likely to offend the Windows folks and the Unix folks equally :-) > > The > > patch was not applied because of the use of that comma. There was also > > some > > desire to support elements instead of just an attribute, something like > > <javac> > > <srcdir name="xyz"> > > <srcdir name="abc"> > > </javac> > > > > I have changed my approach now to use the more "forgiving" ways of > > Project.translatePath. I have added a method to Project called > > translatePathInternal. Whereas translatePath will translate a path to the > > local platform conventions, this new method translates paths, whether > > specified with ":/" or ";\", to a platform independent format based on ':' > > and '/' but supporting DOS drive style paths (C:\...). This path can then > > be > > tokenized on the ':' character to build the source paths vector. So you > > can > > specify the path in either Windows or Unix style and it should work on > > either platform. I'm not sure how other platforms react :-) I still > > haven't > > added the element approach yet. > > > > > > For dependency tracking I took a different approach from you. I separated > > dependency analysis into a new task <depend>. The depend task builds a > > dependency file by analysing the given set of class files (either a > > directory or a jar). Javac uses the dependency file to determine which > > classes are affected by classes being recompiled. In theory the dependency > > file could be built in some other way but still be used by Javac. The > > dependency format is pretty simple and could be changed easily. > > > > Example usage > > <javac srcdir="${src1.dir}:${src2.dir};${src3.dir}" > > destdir="${build.classes}" > > classpath="${build.classpath}" > > debug="on" > > deprecation="on" > > depfile="${build.dir}/depfile.txt"> > > </javac> > > <depend src="${build.classes}" depfile="${build.dir}/depfile.txt" /> > > > > I also only follow direct relationships. Say you have a scenario of A > > depends on B and B depends on C but A does not depend on C. If you change > > C, > > my approach will only compile C and B but not A. My feeling is that if A > > does not depend directly on C, changes to C cannot affect A through B. I'm > > still thinking about that :-) > > > > I can't really say which approach is better. I include my source code (and > > a > > set of diffs) here to let people see an alternative approach. > > [End cut] > > > > Vitaly Stulsky << File: build.xml >> << File: build.xml.diff >> << File: > > Javac.java >> << File: lib.jar >> << File: src.zip >> << File: > > diffs.txt >> __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
