You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Scott Ellsworth <sc...@alodar.com> on 2001/12/06 20:54:01 UTC
fork option for jar task?
Over on the cruise control list, it has been noted that Sun's tools
are rather bad about releasing resources. As best as I can tell, jar
stabbed me in the back this morning.
There is a fork option for javac that seems to fix the problem for
it, but there is no corresponding one for jar.
Any chance of that making it in the 1.5 build? (Speaking of which,
anyone have a guess about when 1.5 will hit? I know that CC2 is not
likely much, if any before Christmas, so if it is in that time frame,
the authors may get a chance to test against the latest and greatest.)
Scott
--
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: fork option for jar task?
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 11 Dec 2001, Scott Ellsworth <sc...@alodar.com> wrote:
> The only strange bit is that the jar is used in later stages of the
> build as part of the javac classpath for other items.
Using JDK 1.3?
The modern compiler has a resource leak and won't close ZIP files that
are on the CLASSPATH after reading them. The workaround is to set
fork="true" on the javac task. See also
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3345>
> I got various and sundry error messages about not being able to find
> javac on Linux when I tried using the fork=yes option to javac,
We should address these, then. Works for me on Linux, BTW.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: fork option for jar task?
Posted by Scott Ellsworth <sc...@alodar.com>.
>On Sat, 8 Dec 2001, Scott Ellsworth <sc...@alodar.com> wrote:
>
>> I believe it is a problem in the jar tasks. If I build my jar with
>> the jar task under cruise control, the file is at least occasionally
>> marked as still open.
>
>Are you doing something with this jar except creating it during the
>build process? The code of Zip.java seems to close the file no matter
>which execution path has been taken.
The only strange bit is that the jar is used in later stages of the
build as part of the javac classpath for other items. For example,
we build metagraph.jar as the first step, and import.jar, view.jar,
and query.jar all import stuff from it when we build those three jars
later.
I have not seen the symptom in a couple of days, during which we had
several builds, so it may be that switching to the "throw out all
.class files" target for every build has helped.
(I got various and sundry error messages about not being able to find
javac on Linux when I tried using the fork=yes option to javac, so I
just used the "clean build" target)
Could it be that javac was holding a lock on it at the second compile?
Scott
--
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: fork option for jar task?
Posted by Stefan Bodewig <bo...@apache.org>.
On Sat, 8 Dec 2001, Scott Ellsworth <sc...@alodar.com> wrote:
> I believe it is a problem in the jar tasks. If I build my jar with
> the jar task under cruise control, the file is at least occasionally
> marked as still open.
Are you doing something with this jar except creating it during the
build process? The code of Zip.java seems to close the file no matter
which execution path has been taken.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: fork option for jar task?
Posted by Scott Ellsworth <sc...@alodar.com>.
At 7:47 AM +0100 12/7/01, Stefan Bodewig wrote:
>On Thu, 6 Dec 2001, Scott Ellsworth <sc...@alodar.com> wrote:
>
>> Over on the cruise control list, it has been noted that Sun's tools
>> are rather bad about releasing resources. As best as I can tell,
>> jar stabbed me in the back this morning.
>
>We don't use command line jar for the <jar> task, but a home brewed
>reimplementation of ZipOutputStream. What is the problem you are
>seeing? If it can be tracked down to the jar tasks, it probably is an
>Ant bug.
I believe it is a problem in the jar tasks. If I build my jar with
the jar task under cruise control, the file is at least occasionally
marked as still open. If it is an NFS mounted drive, it is not
replaced. NFS does this if a file handle to the file is still open.
This would not show up if the same jar was not built twice by the
same process, so most uses of ANT would not suffer this failure.
(Cruise control does not exit the process after a build - instead,
the same process does all of the builds.)
The target for this is dirt simple:
<target name="dist-debug" depends="compile-debug"
description="Build release jar">
<jar
jarfile="${dist}/${baseJarName}-${DSTAMP}-debug.jar"
basedir="${build-debug}"
compress="false"
/>
</target>
Scott
--
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: fork option for jar task?
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 6 Dec 2001, Scott Ellsworth <sc...@alodar.com> wrote:
> Over on the cruise control list, it has been noted that Sun's tools
> are rather bad about releasing resources. As best as I can tell,
> jar stabbed me in the back this morning.
We don't use command line jar for the <jar> task, but a home brewed
reimplementation of ZipOutputStream. What is the problem you are
seeing? If it can be tracked down to the jar tasks, it probably is an
Ant bug.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>