ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject Re: Javac task query
Date Wed, 27 Jun 2007 09:09:23 GMT
Yadav, Akshat Kumar wrote:
> Thanks Peter for reply.
> 
> I think ANT developer should think on extending there "javac" task to
> provide such feature. 
> 
> Thanks,
> 

I must disagree. You should get into the habit of doing clean builds on 
a regular basis, at least first thing every morning when you check out 
the updated code, and *before you create any redistributables*

there's too many ways that .class files can creep in to the 
build/classes output other than just compiling source
  rmic
  wsdl2java and a separate javac
  jaxb tasks and a separate javac
  classes in the wrong package/class file name

by having a separate directory for all build time output, a simple 
<delete> operation purges your build of all leftover state from  the 
previous one, and guarantees that what you ship is what is in CVS/SVN.

For reference, the way we cut releases at work, I have a separate VMware 
image (Xubuntu 6.04) purely for checking out code and building releases 
on java1.5. It doesnt get used for development, purely checking out, 
building, testing, publishing. Every build it even purges the ~/.ivy 
directories of artifacts, forcing a clean download by ivy of external files.

that way we know that what we ship is what we can build repeatedly, not 
whatever was on some developers hdd at the time

-steve


> -----Original Message-----
> From: Peter Reilly [mailto:peter.kitt.reilly@gmail.com] 
> Sent: Wednesday, June 27, 2007 3:46 PM
> To: Ant Users List
> Subject: Re: Javac task query
> 
> On 6/27/07, Yadav, Akshat Kumar <akshat.kumar.yadav@citi.com> wrote:
>> Thanks Prashant for reply.
>>
>> I am talking for the situation where a.java, b.java and c.java are 
>> independent java code files.
>>
>> Thanks,
>>
> <javac/> does not remove the c.class file if the c.java file does not
> exist.
> - i.e. it has no memory of previous compiles. and there may be another
> <javac> task in the build file that could build c.class.
> 
> There are a number of times when similar things happen, if a.java
> changes a method signature and b.java uses a.java's method, b.java needs
> to be recompiled, but <javac/> does not know this.
> 
> 
> The common way to deal with problems like this is to have a build
> directory for *all* the build artifacts (.class files, generated java
> files, .jar files, javadoc, code coverage files, junit reports,  etc)
> and have a "clean" target that simply deletes the build directory:
> 
> <target name="clean">
>    <delete dir="build"/>
> </target>
> 
> Peter
> 
>> -----Original Message-----
>> From: Prashant Reddy [mailto:prashant@pramati.com]
>> Sent: Wednesday, June 27, 2007 1:57 PM
>> To: Ant Users List
>> Subject: Re: Javac task query
>>
>> No 'javac' task by itself will not delete class file whose source java
> 
>> file has been deleted, and rightly so.
>>
>> I do not think you would really want other source files to *not* 
>> compile when you have deleted a dependent source file.
>>
>> Imagine class A uses class C and you deleted class C (manually, and 
>> not using a modern IDE). Even though the time stamp for class A did 
>> not change, you would want to recompile both A, and C.
>>
>> You could have a cleancompile target in your build.xml
>>
>> <target name="cleancompile" depends="remove.classes.dir, compile, 
>> jar"/>
>>
>> The "remove.classes.dir" target would remove all the class files from 
>> the ${dest} directory.
>>
>> In the sited Phase 2, you would run the cleancompile target, instead 
>> of simple 'jar' target. This would remove C.class along with other 
>> class files from ${dest} directory. During the next compilation since 
>> C.java is deleted C.class will not be generated, and you jar will not 
>> have c.class.
>>
>> Hope this helps.
>>
>> -Prashant
>> On Wed, 2007-06-27 at 10:10 +0800, Yadav, Akshat Kumar wrote:
>>> Thanks Steve! It worked.
>>>
>>> But lets say if I have executed compile target on a.java, b.java 
>>> ,c.java it generates a.class, b.class, c.class and then I made jar 
>>> of these class files. Later if I deleted c.java from source and its 
>>> class
>>> file is present is in dest dir. And when I will make jar it will 
>>> contain c.class also, that I don't want to be persent in jar file as
> 
>>> its corresponding java file is deleted from source dir.
>>>
>>> Reference:
>>> Phase 1:
>>> Source: a.java, b.java, c.java
>>> Dest: a.class, b.class, c.class
>>> Jar: JTQ.jar (contains a.class, b.class, c.class)
>>>
>>> Phase 2 (when I deleted c.java from source dir)
>>> Source: a.java, b.java
>>> Dest: a.class, b.class, c.class
>>> Jar: JTQ.jar (contains a.class, b.class, c.class)
>>>
>>> But I don't want c.class should not be presend in jar. It there any 
>>> option or method to counter with such situation.
>>>
>>> Any help appreciated. If my query is not clear, then let me know...
>>>
>>> Thanks,
>>>
>>> -----Original Message-----
>>> From: Steve Loughran [mailto:stevel@apache.org]
>>> Sent: Tuesday, June 26, 2007 7:04 PM
>>> To: Ant Users List
>>> Subject: Re: Javac task query
>>>
>>> Yadav, Akshat Kumar wrote:
>>>> Hi Prashant,
>>>>
>>>> I had executed ANT in verbose and debug mode and it shows
>>>>
>>>>  [javac] HelloWorlApp.java added as HelloWorlApp.class doesn't
>> exist.
>>>> Whereas the class file exist in dest dir. I tried adding/deleting 
>>>> dest
>>>> dir in classpath, but no luck in both the situation.
>>>>
>>>> I would appreciate, If you could try this in your environment. I 
>>>> had
>>>> tried this with ANT 1.6.5/1.7 and java 1.4/1.5.
>>>>
>>>> P.S: Other member's can also suggest me something.
>>>>
>>>> Thanks,
>>> could be the classname in the .java file has a different spelling or
> 
>>> case from the source file itself
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: user-unsubscribe@ant.apache.org For 
>>> additional
>>> commands, e-mail: user-help@ant.apache.org
>>>
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: user-unsubscribe@ant.apache.org For 
>>> additional
>>> commands, e-mail: user-help@ant.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org For additional
> 
>> commands, e-mail: user-help@ant.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org For additional
> 
>> commands, e-mail: user-help@ant.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org For additional
> commands, e-mail: user-help@ant.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


Mime
View raw message