ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Goldstein, Joel" <j...@eccelerate.com>
Subject RE: javac dependencies
Date Mon, 12 Jun 2000 16:55:46 GMT
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:vitaly_stulsky@yahoo.com]
> Sent:	Thursday, June 08, 2000 7:38 AM
> To:	Ant-Dev@Jakarta.Apache.Org
> 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 >> 


Mime
View raw message