You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by FU...@de.ibm.com on 2000/07/03 19:08:24 UTC
WIBNI for Javac Task
I have recently started using Ant and came up with a few ideas while
migrating my build process to it. My directory structure is as follows:
Source tree:
/projects/src/servlet/client/Main.java
Classes tree:
/projects/classes/com/ibm/workflow/servlet/client/Main.class
That is, to avoid too much typing I put Main.java (and all the other files)
which is in the 'com.ibm.workflow.servlet.client' package in the
'servlet/client' subtree of my source tree.
Now when I compile my sources using the following task
<javac srcdir="/projects/src"
destdir="/project/classes"
includes="servlet/client/*.java"/>
It always recompiles all sources. This is because javac compares the
directories, but is missing the 'com/ibm/workflow' part of the directory.
A workaround is to first copy the sources to a fully named directory and
then compile from there:
<copydir src="/projects/src"
dest="/projects/ant/com/ibm/workflow"
includes="servlet/client/*.java"/>
<javac srcdir="/projects/ant"
destdir="/projects/classes"
includes="**/servlet/client/*.java"/>
But I don't like this approach so I thought one might simply add an
optional 'pkgdir' parameter to javac which would be used when comparing
srcdir and destdir. The task would then read like this:
<javac_pkg srcdir="/projects/src"
destdir="/projects/classes"
pkgdir="com/ibm/workflow"
includes="servlet/client/*.java"/>
I have already implemented this, it is just a few lines:
private String pkgDirName;
:
public void setPkgdir(String pkgDirName) {
this.pkgDirName = pkgDirName;
}
:
File pkgDir = pkgDirName == null ? destDir : new File(destDir,
pkgDirName);
scanDir(srcDir, pkgDir, files);
// compile the source files
:
What do you think?
-Erich
RE: WIBNI for Javac Task
Posted by Peter Donald <do...@mad.scientist.com>.
At 09:53 4/7/00 +0930, you wrote:
>Forgive my persistence, and it's been a while since I hacked through
>this code, but I thought ant decided which files to recompile _before_
>passing them on to javac (at least for the classic compiler). I was
>under the impression that it found all the source files specified,
>worked out where they would end up (this bit may be a bit wonky if
>your directory structure doesn't match, I guess) and compared
>timestamps. Then if it needed recompiling, the file found it's way to
>the javac command line. Isn't this the way it works? Or is my view of
>the world going to be torn apart? ;-)
you got it right but the all javac's and jikes cmds also do the same
checking in their own code and redo everything based on input. (Thou Javac
does it in a wonky way). For instance in every package I used to have a
file like
public class PackageList
{
public final static Class MyClass_class = MyClass.class;
public final static Class MyClass2_class = MyClass2.class;
public final static Class MyClass3_class = MyClass3.class;
}
Everytime I compiled Package list it would compile all files changed in
that package.
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
RE: WIBNI for Javac Task
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
> -----Original Message-----
> From: Tom Cook [mailto:tcook@ardec.com.au]
> Sent: Tuesday, 4 July 2000 10:23
> To: ant-dev@jakarta.apache.org
> Subject: RE: WIBNI for Javac Task
>
>
> Forgive my persistence, and it's been a while since I hacked through
> this code, but I thought ant decided which files to recompile _before_
> passing them on to javac (at least for the classic compiler). I was
> under the impression that it found all the source files specified,
> worked out where they would end up (this bit may be a bit wonky if
> your directory structure doesn't match, I guess) and compared
> timestamps. Then if it needed recompiling, the file found it's way to
> the javac command line. Isn't this the way it works? Or is my view of
> the world going to be torn apart? ;-)
>
Yes and No :-)
Say you want to compile just a single package (selecting it with an include
element), the javac task will determine all files in that package that need
to be recompiled and pass these to the javac tool. Now the tool will examine
these files and determine the classes upon which these files depend. Say
some of these dependencies are not in the list passed from the javac task.
The javac tool needs to find (or generate) a .class file for these
dependencies. If it can't find the .class file in the classpath it will try
to generate it by finding and compiling a .java file in the source path. The
full algorithm it uses for this search is described in the javac tool
documentation.
Conor
RE: WIBNI for Javac Task
Posted by Tom Cook <tc...@ardec.com.au>.
Conor MacNeill writes:
> > -----Original Message-----
> > From: Tom Cook [mailto:tcook@ardec.com.au]
> >
> >
> > I was under the impression that ant found each source file, and worked
> > out where the destination file would end up, and then do comparisons
> > on them. This works fairly faultlessly for me - are you using the 3.1
> > release, or the latest CVS source? The release is hopelessly out
> > of date...
> >
> > Regards
> > Tom
>
> The issue is that Erich's directory structure does not match his package
> structure. I am not sure this is a good idea. When javac (the tool, not the
> task) is compiling a class and it cannot find a class upon which the current
> class depends, it attempts to find a source file, mapping the package
> structure to the sourcepath. Have a look at "SEARCHING FOR TYPES" in the
> Javac documentation. In all our projects, our source directory structure and
> package structure match.
Forgive my persistence, and it's been a while since I hacked through
this code, but I thought ant decided which files to recompile _before_
passing them on to javac (at least for the classic compiler). I was
under the impression that it found all the source files specified,
worked out where they would end up (this bit may be a bit wonky if
your directory structure doesn't match, I guess) and compared
timestamps. Then if it needed recompiling, the file found it's way to
the javac command line. Isn't this the way it works? Or is my view of
the world going to be torn apart? ;-)
Regards
Tom
Re: WIBNI for Javac Task
Posted by Vitaly Stulsky <vi...@yahoo.com>.
> The issue is that Erich's directory structure does not match his package
> structure. I am not sure this is a good idea. When javac (the tool, not
the
> task) is compiling a class and it cannot find a class upon which the
current
> class depends, it attempts to find a source file, mapping the package
> structure to the sourcepath. Have a look at "SEARCHING FOR TYPES" in the
> Javac documentation. In all our projects, our source directory structure
and
> package structure match.
>
I've thought about this problem too. From my point of view it is neccesssary
to
add sourcepath attribute to the javac taskdef. I've done it for my local
version of ant.
There are few benefits:
1) it is possible to enumerate not all files in one direcory, but select
necessary packages
from it and compile them (e.g. we had some kind of utility classes
repository and I
included packages from this repository into my project, cause I didn't need
all utility
classes in my final distribution).
2) it's easy to locate class file even if user specify 'incorrect' path to
sources (e.g he/she
specifies path not to the first package 'org', but to directory under the
first package 'org').
Any ideas?
Vitaly
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
RE: WIBNI for Javac Task
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
> -----Original Message-----
> From: Tom Cook [mailto:tcook@ardec.com.au]
>
>
> I was under the impression that ant found each source file, and worked
> out where the destination file would end up, and then do comparisons
> on them. This works fairly faultlessly for me - are you using the 3.1
> release, or the latest CVS source? The release is hopelessly out
> of date...
>
> Regards
> Tom
The issue is that Erich's directory structure does not match his package
structure. I am not sure this is a good idea. When javac (the tool, not the
task) is compiling a class and it cannot find a class upon which the current
class depends, it attempts to find a source file, mapping the package
structure to the sourcepath. Have a look at "SEARCHING FOR TYPES" in the
Javac documentation. In all our projects, our source directory structure and
package structure match.
Erich, would you consider aligning your source tree with your package
structure?
Conor
WIBNI for Javac Task
Posted by Tom Cook <tc...@ardec.com.au>.
I was under the impression that ant found each source file, and worked
out where the destination file would end up, and then do comparisons
on them. This works fairly faultlessly for me - are you using the 3.1
release, or the latest CVS source? The release is hopelessly out of date...
Regards
Tom
FUSSI@de.ibm.com writes:
>
>
> I have recently started using Ant and came up with a few ideas while
> migrating my build process to it. My directory structure is as follows:
>
> Source tree:
> /projects/src/servlet/client/Main.java
>
> Classes tree:
> /projects/classes/com/ibm/workflow/servlet/client/Main.class
>
> That is, to avoid too much typing I put Main.java (and all the other files)
> which is in the 'com.ibm.workflow.servlet.client' package in the
> 'servlet/client' subtree of my source tree.
>
> Now when I compile my sources using the following task
>
> <javac srcdir="/projects/src"
> destdir="/project/classes"
> includes="servlet/client/*.java"/>
>
> It always recompiles all sources. This is because javac compares the
> directories, but is missing the 'com/ibm/workflow' part of the directory.
>
> A workaround is to first copy the sources to a fully named directory and
> then compile from there:
>
> <copydir src="/projects/src"
> dest="/projects/ant/com/ibm/workflow"
> includes="servlet/client/*.java"/>
> <javac srcdir="/projects/ant"
> destdir="/projects/classes"
> includes="**/servlet/client/*.java"/>
>
> But I don't like this approach so I thought one might simply add an
> optional 'pkgdir' parameter to javac which would be used when comparing
> srcdir and destdir. The task would then read like this:
>
> <javac_pkg srcdir="/projects/src"
> destdir="/projects/classes"
> pkgdir="com/ibm/workflow"
> includes="servlet/client/*.java"/>
>
> I have already implemented this, it is just a few lines:
>
> private String pkgDirName;
> :
> public void setPkgdir(String pkgDirName) {
> this.pkgDirName = pkgDirName;
> }
> :
> File pkgDir = pkgDirName == null ? destDir : new File(destDir,
> pkgDirName);
> scanDir(srcDir, pkgDir, files);
>
> // compile the source files
> :
>
> What do you think?
>
> -Erich
>
>