[
https://issues.apache.org/jira/browse/IVY-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858325#action_12858325
]
Maarten Coene commented on IVY-1179:
------------------------------------
Thanks for the patch! Could you re-attach your files and check the "grant
license to ASF..." option?
> Packager resolver always extracts all files from archives even when the
> packaging instructions contains include tags
> --------------------------------------------------------------------------------------------------------------------
>
> Key: IVY-1179
> URL: https://issues.apache.org/jira/browse/IVY-1179
> Project: Ivy
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.1.0, trunk
> Reporter: Stefan De Boey
> Priority: Minor
> Attachments: IVY-1179-unittests.zip, IVY-1179.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> According to the documentation the packager resolver should unzip/untar only
> specific files and folders (and not the complete archive) from downloaded
> resources in case the packager module description specfies include tags.
> Let's assume we have a module testng (example is taken from the examples in
> the Packager Resolver documentation) and we have a packager module descriptor
> (the packaging instructions) packager.xml specifying the following resource:
> {code:xml}
> <resource dest="archive" url="http://testng.org/${zipname}.zip";
> sha1="2ea19275dc17453306f8bb780fe6ef6e9af7756b">
> <include name="${zipname}/*.jar"/>
> </resource>
> {code}
> this instructs the package resolver to download the resources from
> http://testng.org/... and then extract the archive, but only all JAR files in
> the root of the archive.
> in this case only the JAR's in the ZIP file should be extracted from the
> resource, but that's not the case. at first i didn't notice this, but i was
> creating the packaging instructions for a project which is in a huge ZIP file
> and so i only wanted to extract the files that i actually needed, but i
> noticed that the extraction took way to long.
> i then configured the packager resolver to preserve the build directories
> (where the archive is extracted) for debugging purposes and i noticed that
> the complete archive was still extracted although the packager.xml file
> contained the necessary 'include' tags to only inluce 3 JAR's.
> when using the preserveBuildDirectories switch on the packager resolver, it's
> also possible to view the ANT build file packager-output.xml (this one is
> generated by the packager resolver based on the packaging instructions). this
> build file is executed by the package resolver to do the extraction process.
> this is the relevant part of the packager-output.xml file for the above
> mentioded example for TestNG:
> {code:xml}
> <unzip src="${resdir.N65541}${file.separator}${filename.N65541}"
> dest="archive">
> <fileset dir=".">
> <include name="testng-2.5/*.jar"/>
> </fileset>
> </unzip>
> {code}
> but this is incorrect and that's why the complete zip is still extracted. the
> 'fileset' tag should be used to indicate a set of ZIP files that need to be
> extracted, not to indicate which resources from the archive (specified in the
> 'src' attribute of the unzip tag) need to be included when extracting.
> 'patternset' is what we need here instead of 'fileset'
> the actual problem is situated in the file
> src/java/org/apache/ivy/plugins/resolver/packager/packager.xsl on line 420
> (in the ivy core project).
> {code:xml}
> <xsl:when test="$type = 'zip' or $type = 'war' or $type = 'jar'">
> <unzip src="{$file}" dest="{$dir}">
> <xsl:if test="$includes">
> <fileset dir=".">
> <xsl:copy-of select="$includes"/>
> </fileset>
> </xsl:if>
> </unzip>
> </xsl:when>
> {code}
> should be:
> {code:xml}
> <xsl:when test="$type = 'zip' or $type = 'war' or $type = 'jar'">
> <unzip src="{$file}" dest="{$dir}">
> <xsl:if test="$includes">
> <patternset>
> <xsl:copy-of select="$includes"/>
> </patternset>
> </xsl:if>
> </unzip>
> </xsl:when>
> {code}
> the same needs to be done for the TAR part in the packages.xsl file.
> i already tried this fix and it works.
> if that's OK, i'll create a patch for this and provide the necessary unit
> tests to illustrate the problem and the fix.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
