ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vitaly Stulsky" <vitaly_stul...@yahoo.com>
Subject RE: javac dependencies
Date Mon, 12 Jun 2000 18:46:23 GMT
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:joel@eccelerate.com]
> 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: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 >> 

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

Mime
View raw message