Summary: | jar task, nested element "service" not merged | ||
---|---|---|---|
Product: | Ant | Reporter: | Nam3l3ss <nam3l3ssa> |
Component: | Core tasks | Assignee: | Ant Notifications List <notifications> |
Status: | NEW --- | ||
Severity: | minor | CC: | jglick |
Priority: | P2 | ||
Version: | 1.8.1 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Linux |
Description
Nam3l3ss
2011-04-20 13:06:56 UTC
Since the zip format does permit same-named entries, are you sure that C.jar isn't still capable of providing multiple service provider implementations despite these actually being represented in different jar entries? I'm practically sure, but I'll create a presentable test case as soon as I have some time. (In reply to comment #1) > Since the zip format does permit same-named entries, are you sure that C.jar > isn't still capable of providing multiple service provider implementations > despite these actually being represented in different jar entries? sun.misc.URLClassPath.JarLoader.getResource can only return one resource, since it is using JarFile.getJarEntry. Iterating all entries would be inefficient, and there is no method in JarFile to get multiple entries with the same name. Probably there is some way to write the script to concatenate META-INF/services/* entries from its inputs, but it does not sound easy. Maybe use a custom task - either a subclass of Zip which overrides zipFile and knows how to merge these entries, or set duplicate=add and then run a separate task to merge entries in the result. In general it would be nice to have a helper type ResourceMerger, which you could pass to <zip>, <copy>, etc.; one impl could simply concatenate the incoming resources, but custom impls could perform more complex merges. |