Hi Marc, When not specifying the packaging attribute, everything seems to work as expected. I suppose I could always write a custom Ant action to unzip the files. I was trying to use the Ivy feature.
Here is my current cache configuration in ivysettings.xml : <caches ivyPattern="[organisation]/[module]/[revision]/[artifact](-[arch])(-[compiler])(-[locInfo])-[revision].xml" artifactPattern="[organisation]/[module]/[revision]/[artifact](-[arch])(-[compiler])(-[locInfo])-[revision](-[classifier]).[ext]" /> Of course, [arch], [compiler] and [locInfo] are extra-attributes that are defined in the library I'm resolving from Artifactory. Here is the ivy.xml file of that library: <ivy-module version="2.0" xmlns:e="http://ant.apache.org/ivy/extra"> <info organisation="com.trilliantinc" module="slf4ec" /> <configurations> <conf name="cortex-m4_gcc_withLoc" e:arch="cortex-m4" e:compiler="gcc" e:locInfo="withLoc" description="Binary for ARM Cortex-M4 compiled with GCC with location information" /> <conf name="cortex-m4_gcc_withoutLoc" e:arch="cortex-m4" e:compiler="gcc" e:locInfo="withoutLoc" description="Binary for ARM Cortex-M4 compiled with GCC without location information" /> <conf name="cortex-m4_iar_withLoc" e:arch="cortex-m4" e:compiler="iar" e:locInfo="withLoc" description="Binary for ARM Cortex-M4 compiled with IAR with location information" /> <conf name="cortex-m4_iar_withoutLoc" e:arch="cortex-m4" e:compiler="iar" e:locInfo="withoutLoc" description="Binary for ARM Cortex-M4 compiled with IAR without location information" /> <conf name="x86_gcc_withLoc" e:arch="x86" e:compiler="gcc" e:locInfo="withLoc" description="Binary for x86 compiled with GCC with location information" /> <conf name="x86_gcc_withoutLoc" e:arch="x86" e:compiler="gcc" e:locInfo="withoutLoc" description="Binary for x86 compiled with GCC without location information" /> <conf name="artifacts" visibility="private" description="Build's artifacts" /> <conf name="all" extends="*" description="All artifacts" /> </configurations> <publications> <artifact name="slf4ec" e:arch="x86" e:compiler="gcc" e:locInfo="withLoc" ext="zip" type="native" conf="x86_gcc_withLoc" packaging="zip" /> <artifact name="slf4ec" e:arch="x86" e:compiler="gcc" e:locInfo="withoutLoc" ext="zip" type="native" conf="x86_gcc_withoutLoc" packaging="zip" /> <artifact name="slf4ec" e:arch="cortex-m4" e:compiler="gcc" e:locInfo="withLoc" ext="zip" type="native" conf="cortex-m4_gcc_withLoc" packaging="zip" /> <artifact name="slf4ec" e:arch="cortex-m4" e:compiler="gcc" e:locInfo="withoutLoc" ext="zip" type="native" conf="cortex-m4_gcc_withoutLoc" packaging="zip" /> <artifact name="slf4ec" e:arch="cortex-m4" e:compiler="iar" e:locInfo="withLoc" ext="zip" type="native" conf="cortex-m4_iar_withLoc" packaging="zip" /> <artifact name="slf4ec" e:arch="cortex-m4" e:compiler="iar" e:locInfo="withoutLoc" ext="zip" type="native" conf="cortex-m4_iar_withoutLoc" packaging="zip" /> <artifact name="doc" ext="zip" type="html" conf="artifacts" packaging="zip" /> <artifact name="tests" ext="zip" type="xUnit" conf="artifacts" packaging="zip" /> </publications> </ivy-module> I'm not exactly sure what use the extra-attributes could have inside the <conf /> section. Currently they don’t seem to impact anything and I'm probably going to remove them. Ideally I would have proffered to use these extra-attributes instead of configurations (and a long configuration name string) when resolving dependencies, but the resolver looks for these extra-attributes in the module, not the artifacts so cannot resolve when using extra-attributes. At least that's what I found out with my experimentations. Best regards, Jérémie -----Original Message----- From: Marc De Boeck [mailto:mdeb...@gmail.com] Sent: June 29, 2016 4:16 PM To: ivy-user@ant.apache.org Subject: Re: Packaging attribute, unpack location Can you tell us the cache pattern that you have configured ? Maybe you can also try to retrieve the same artifacts but with a module descriptor (ivy-file) where the packaging attribute is not set. This way, you could find out if it is related to the packaging attribute, or related to something else. Regards, Marc 2016-06-29 21:22 GMT+02:00 Jeremie Faucher-Goulet < jeremie.faucher-gou...@trilliantinc.com>: > Hello, > > > > I’m encountering an issue where, when using a different configuration > for the same artifact during a retrieve operation, the artifact is > downloaded but the wrong artifact is copied in my project. > > Is it a limitation of the automatic unpacking (zip file in my case) > not keeping the extra attributes? I’m new to Ivy so there might be a > configuration option I haven’t found yet. > > > > For example, I’m using a custom pattern for the Ivy cache so I can get > the different configuration downloaded and a similar custom pattern > for the retrieve itself so I can get these different artifacts in my project. > However, calling retrieve with a different configuration does create a > new folder in my project (retrieve pattern), but it’s content is the > same as with the previous configuration. > > Looking in the Ivy cache, I see that the download did create a new > (proper) artifact in my cache according to my custom cache pattern, > but the same folder was used (and not overridden) for unpacking. > > > > It seems whatever pattern I set, the unpacking location will happen > here in the cache: > [organisation]/[module]/[revision]/[artifact]-[revision]/* > > > > My assumption currently, is that Ivy will find the same unpacking > location so will skip the unpacking step. Retrieve will then copy over > a dirty/invalid version of what was unpacked. Are my assumptions correct? > > > > Is there a way to configure the unpacking location, if my > understanding of the issue is correct? > > > > P.S. I’m using configuration to differentiate different native C/C++ > builds (x86, arm, etc…) Perhaps I’m not using the proper approach? > > > > Thank you, > > > > [image: Description: cid:image001.jpg@01C9B6D4.5B951A30] > > Jeremie Faucher-Goulet, Jr. Eng. > Firmware Developer > Trilliant Inc > Tel: 450.375.0556 ext. 368 > jeremie.faucher-gou...@trilliantinc.com > > www.trilliantinc.com > > > > >