You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Justin Georgeson <JG...@lgc.com> on 2011/11/07 20:45:37 UTC
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 src.zip 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}/src.zip' and then build (build-external-unzip.log) the javadocs do inherit from javax.naming.Context. I've tried using 'jar xvf ${JAVA_HOME}/src.zip' and that has the same result as using the <unzip> task. The javax/naming/Context.java file is the same (compared MD5 checksums) no matter how I uncompress src.zip.
-----Original Message-----
From: Justin Georgeson
Sent: Friday, November 04, 2011 2:21 PM
To: user@ant.apache.org
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 src.zip in the 'src' folder that my source code is in, there's no javadoc inheritance.
-----Original Message-----
From: Justin Georgeson [mailto:JGeorgeson@lgc.com]
Sent: Friday, November 04, 2011 1:35 PM
To: user@ant.apache.org
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}/src.zip 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}/src.zip' 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.
RE: difference between unzip task and unzip executable
Posted by Justin Georgeson <JG...@lgc.com>.
Thanks. I've commented below
> -----Original Message-----
> From: Rainer Noack [mailto:rainer@noacks.net]
> Sent: Monday, November 07, 2011 2:37 PM
> To: dev@ant.apache.org; 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 src.zip. (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 src.zip 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 src.zip, the problem exists (also if I use the ${JAVA_HOME}/bin/jar command to extract src.zip). 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 http://www.info-zip.org/pub/infozip/UnZip.html. 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 oracle.com 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
> >
> > http://www.mediafire.com/?a1snm5i1n7tsmdx
> >
> > -----Original Message-----
> > From: Justin Georgeson [mailto:JGeorgeson@lgc.com]
> > Sent: Monday, November 07, 2011 1:46 PM
> > To: dev@ant.apache.org
> > 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 src.zip 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}/src.zip' and then
> build (build-external-unzip.log) the javadocs do inherit from
> javax.naming.Context. I've tried using 'jar xvf ${JAVA_HOME}/src.zip' and that
> has the same result as using the<unzip> task. The javax/naming/Context.java
> file is the same (compared MD5 checksums) no matter how I uncompress src.zip.
> >
> > -----Original Message-----
> > From: Justin Georgeson
> > Sent: Friday, November 04, 2011 2:21 PM
> > To: user@ant.apache.org
> > 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 src.zip in the 'src' folder that my source code is in, there's
> no javadoc inheritance.
> >
> > -----Original Message-----
> > From: Justin Georgeson [mailto:JGeorgeson@lgc.com]
> > Sent: Friday, November 04, 2011 1:35 PM
> > To: user@ant.apache.org
> > 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}/src.zip 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}/src.zip' 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: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: difference between unzip task and unzip executable
Posted by Justin Georgeson <JG...@lgc.com>.
Thanks. I've commented below
> -----Original Message-----
> From: Rainer Noack [mailto:rainer@noacks.net]
> Sent: Monday, November 07, 2011 2:37 PM
> To: dev@ant.apache.org; 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 src.zip. (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 src.zip 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 src.zip, the problem exists (also if I use the ${JAVA_HOME}/bin/jar command to extract src.zip). 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 http://www.info-zip.org/pub/infozip/UnZip.html. 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 oracle.com 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
> >
> > http://www.mediafire.com/?a1snm5i1n7tsmdx
> >
> > -----Original Message-----
> > From: Justin Georgeson [mailto:JGeorgeson@lgc.com]
> > Sent: Monday, November 07, 2011 1:46 PM
> > To: dev@ant.apache.org
> > 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 src.zip 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}/src.zip' and then
> build (build-external-unzip.log) the javadocs do inherit from
> javax.naming.Context. I've tried using 'jar xvf ${JAVA_HOME}/src.zip' and that
> has the same result as using the<unzip> task. The javax/naming/Context.java
> file is the same (compared MD5 checksums) no matter how I uncompress src.zip.
> >
> > -----Original Message-----
> > From: Justin Georgeson
> > Sent: Friday, November 04, 2011 2:21 PM
> > To: user@ant.apache.org
> > 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 src.zip in the 'src' folder that my source code is in, there's
> no javadoc inheritance.
> >
> > -----Original Message-----
> > From: Justin Georgeson [mailto:JGeorgeson@lgc.com]
> > Sent: Friday, November 04, 2011 1:35 PM
> > To: user@ant.apache.org
> > 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}/src.zip 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}/src.zip' 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: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: difference between unzip task and unzip executable
Posted by Rainer Noack <ra...@noacks.net>.
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 src.zip. (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).
2. more ant-friendy: use <ant>-task for the <javadoc>-task.
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."
hope that helps
cheers
rainer
Am 07.11.2011 20:52, schrieb Justin Georgeson:
> I think it stripped the attachment, so I put it here
>
> http://www.mediafire.com/?a1snm5i1n7tsmdx
>
> -----Original Message-----
> From: Justin Georgeson [mailto:JGeorgeson@lgc.com]
> Sent: Monday, November 07, 2011 1:46 PM
> To: dev@ant.apache.org
> 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 src.zip 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}/src.zip' and then build (build-external-unzip.log) the javadocs do inherit from javax.naming.Context. I've tried using 'jar xvf ${JAVA_HOME}/src.zip' and that has the same result as using the<unzip> task. The javax/naming/Context.java file is the same (compared MD5 checksums) no matter how I uncompress src.zip.
>
> -----Original Message-----
> From: Justin Georgeson
> Sent: Friday, November 04, 2011 2:21 PM
> To: user@ant.apache.org
> 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 src.zip in the 'src' folder that my source code is in, there's no javadoc inheritance.
>
> -----Original Message-----
> From: Justin Georgeson [mailto:JGeorgeson@lgc.com]
> Sent: Friday, November 04, 2011 1:35 PM
> To: user@ant.apache.org
> 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}/src.zip 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}/src.zip' 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: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
Re: difference between unzip task and unzip executable
Posted by Rainer Noack <ra...@noacks.net>.
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 src.zip. (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).
2. more ant-friendy: use <ant>-task for the <javadoc>-task.
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."
hope that helps
cheers
rainer
Am 07.11.2011 20:52, schrieb Justin Georgeson:
> I think it stripped the attachment, so I put it here
>
> http://www.mediafire.com/?a1snm5i1n7tsmdx
>
> -----Original Message-----
> From: Justin Georgeson [mailto:JGeorgeson@lgc.com]
> Sent: Monday, November 07, 2011 1:46 PM
> To: dev@ant.apache.org
> 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 src.zip 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}/src.zip' and then build (build-external-unzip.log) the javadocs do inherit from javax.naming.Context. I've tried using 'jar xvf ${JAVA_HOME}/src.zip' and that has the same result as using the<unzip> task. The javax/naming/Context.java file is the same (compared MD5 checksums) no matter how I uncompress src.zip.
>
> -----Original Message-----
> From: Justin Georgeson
> Sent: Friday, November 04, 2011 2:21 PM
> To: user@ant.apache.org
> 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 src.zip in the 'src' folder that my source code is in, there's no javadoc inheritance.
>
> -----Original Message-----
> From: Justin Georgeson [mailto:JGeorgeson@lgc.com]
> Sent: Friday, November 04, 2011 1:35 PM
> To: user@ant.apache.org
> 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}/src.zip 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}/src.zip' 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: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
RE: difference between unzip task and unzip executable
Posted by Justin Georgeson <JG...@lgc.com>.
I think it stripped the attachment, so I put it here
http://www.mediafire.com/?a1snm5i1n7tsmdx
-----Original Message-----
From: Justin Georgeson [mailto:JGeorgeson@lgc.com]
Sent: Monday, November 07, 2011 1:46 PM
To: dev@ant.apache.org
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 src.zip 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}/src.zip' and then build (build-external-unzip.log) the javadocs do inherit from javax.naming.Context. I've tried using 'jar xvf ${JAVA_HOME}/src.zip' and that has the same result as using the <unzip> task. The javax/naming/Context.java file is the same (compared MD5 checksums) no matter how I uncompress src.zip.
-----Original Message-----
From: Justin Georgeson
Sent: Friday, November 04, 2011 2:21 PM
To: user@ant.apache.org
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 src.zip in the 'src' folder that my source code is in, there's no javadoc inheritance.
-----Original Message-----
From: Justin Georgeson [mailto:JGeorgeson@lgc.com]
Sent: Friday, November 04, 2011 1:35 PM
To: user@ant.apache.org
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}/src.zip 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}/src.zip' 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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org