ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Georgeson <>
Subject RE: difference between unzip task and unzip executable
Date Mon, 07 Nov 2011 23:22:27 GMT
Thanks. I've commented below

> -----Original Message-----
> From: Rainer Noack []
> Sent: Monday, November 07, 2011 2:37 PM
> To:; Ant Users List
> Subject: Re: difference between unzip task and unzip executable
> Hi Justin,
> sorry, but your question was a little hard to understand which might be
> the reason, that you got no answer until now.
> The reason for your problem is, that ant resolves path-like structures
> when it is parsing the build.xml - file and drops irrelevant entries.
> but your path only becomes relevant after you'd unzipped (which
> happens later on execution-time)
> you can evaluate this as the reason by unzip first (manually) then run
> ant with your build.xml. (comment out delete and unzip tasks) -> should
> work as expected.
> There are some workarounds:
> 1. the hard and ugly way: run ant twice (may be controlled by a batch file).

Tried that by putting the <unzip> in a dedicated target and running Ant once for the
unzip target and a second time for the javadoc target, same result. Also, using the ${JAVA_HOME}/bin/jar
command to extract before running the javadoc target also does not generate inherited
docs. Conversely, if I replace the <unzip> task with an <exec> task calling /usr/bin/unzip,
the javadocs are correct. 

> 2. more ant-friendy: use <ant>-task for the <javadoc>-task.

I'm looking at the manual for this and am a little confused as to how to properly use it.

> 3. try the new ant 1.8.2. feature (see snip from manual path-like
> structures below , i didn't try it out until now)
> /"Since Ant 1.8.2/ the location attribute can also contain a wildcard in
> its last path component (i.e. it can end in a "*") in order to support
> wildcard CLASSPATHs introduced with Java6. Ant will not expand or
> evaluate the wildcards and the resulting path may not work as anything
> else but a CLASSPATH - or even as a CLASSPATH for a Java VM prior to Java6."

I changed the <pathelement path="${basedir}/jdk"/> to use location instead of path,
same result.

As a further point of clarification as to the issue as I currently see it, I think there is
some bug in the <unzip> task and/or the jar command provided with the JDK. 

If I take Ant out of the picture for generating javadocs, and run the ${JAVA_HOME}/bin/javadoc
executable using the arguments listed in a -verbose Ant run, and only use Ant to extract,
the problem exists (also if I use the ${JAVA_HOME}/bin/jar command to extract The
output of javadoc is just illustrating that there is some so-far undetectable difference in
contents from using jar/<unzip> and using unzip executable provided by RedHat built
from The contents produced by jar/<unzip>
are ignored by javadoc (both the executable and the Ant task), while the contents produced
by /usr/bin/unzip are not ignored by javadoc.

So maybe I'm asking the wrong forum, but it seemed the best place to start, and
seems hell-bent on keeping me out of their forums. 

> Am 07.11.2011 20:52, schrieb Justin Georgeson:
> > I think it stripped the attachment, so I put it here
> >
> >
> >
> > -----Original Message-----
> > From: Justin Georgeson []
> > Sent: Monday, November 07, 2011 1:46 PM
> > To:
> > Subject: RE: difference between unzip task and unzip executable
> >
> > I started asking this on the user list, but no response, and it seems deeper
> than just incorrect usage. Apologies if that's what it turns out to be.
> >
> > I've broken it down into a very basic build.xml and single source code file.
> The build.xml has a single target to unzip, and run javadoc. I've attached a
> bz2 archive of the build.xml, the source file, and a -debug log of using the
> unzip task and relying on the having been expanded with the native OS
> unzip command before running. The single source code file implements the
> javax.naming.Context interface. When run as-is (build-internal-unzip.log) the
> javadocs do not inherit from javax.naming.Context. If you comment out lines 6
> and 7 from build.xml and run 'unzip -d jdk ${JAVA_HOME}/' and then
> build (build-external-unzip.log) the javadocs do inherit from
> javax.naming.Context. I've tried using 'jar xvf ${JAVA_HOME}/' and that
> has the same result as using the<unzip>  task. The javax/naming/
> file is the same (compared MD5 checksums) no matter how I uncompress
> >
> > -----Original Message-----
> > From: Justin Georgeson
> > Sent: Friday, November 04, 2011 2:21 PM
> > To:
> > Subject: RE: difference between unzip task and unzip executable
> >
> > Just to eliminate any possibility of file handle closure, disk I/O flushing,
> etc. I put the<unzip>  in a separate target that only does the unzip, ran that
> target by itself, and then ran ant a second time for the javadoc target and it
> still fails. I don't understand what the problem can be when everything says
> the contents of the files are identical. Even if I use the<unzip>  task to put
> the contents of in the 'src' folder that my source code is in, there's
> no javadoc inheritance.
> >
> > -----Original Message-----
> > From: Justin Georgeson []
> > Sent: Friday, November 04, 2011 1:35 PM
> > To:
> > Subject: difference between unzip task and unzip executable
> >
> > I'm trying to get javadoc inheritance working from JDK classes, and what I'm
> finding is if I use
> >
> > <unzip src="${env.JAVA_HOME}/ dest="${env.BUILD_DIR}/docs/jdk"/>
> >
> > in my Ant target, the javadoc task ignores that sourcepath entry because it
> doesn't contain any packages matching my packagenames parameter (running with
> -verbose says it "doesn't contain any packages, dropping it"). If I run 'unzip
> -d ${BUILD_DIR}/docs/jdk ${JAVA_HOME}/' in the shell before running Ant
> (and the target just assumes the folder is there) everything works right. I've
> run a 'diff -qr' on the result of both unzip methods and no differences are
> found, even 'rsync -acv' says they're the same
> >
> > ----------------------------------------------------------------------
> > This e-mail, including any attached files, may contain confidential and
> privileged information for the sole use of the intended recipient.  Any
> review, use, distribution, or disclosure by others is strictly prohibited.  If
> you are not the intended recipient (or authorized to receive information for
> the intended recipient), please contact the sender by reply e-mail and delete
> all copies of this message.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message