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 >>
