Jérémie, Your settings look correct to me. We also work with the extra-attributes to distinguish artifacts, but we don't the package attribute. If I need to unpack something, I do it outside of Ivy in an ant-task (like you suggest as alternative). I also agree that the extra-attributes in the <conf> section are not needed. We don't have them either, but we do use them inside the publications sections. If I have some time tomorrow, I will try to make a test with the package-attribute in our environment and see if I can reproduce your problem.
Regards, Marc 2016-06-29 22:50 GMT+02:00 Jeremie Faucher-Goulet < [email protected]>: > Other useful tidbits.... > > Here is my retrieve task in build.xml: > > <target name="retrieve" description="Resolve dependencies"> > <ivy:retrieve > pattern="lib/[artifact]/[artifact](_[arch])(_[compiler])(_[locInfo])-[revision](-[classifier]).[ext]" > /> > </target> > > So in my cache I get the following directory structure: > > +.ivy2\cache\com.trilliantinc\slf4ec\1.0.0+15.db80236\ > |----+slf4ec-1.0.0+15.db80236 (unpack folder) > |----+slf4ec-x86-gcc-withLoc-1.0.0+15.db80236.zip (artifact downloaded > according to cache pattern) > > > And in my project I get: > > +lib\ > |----+slf4ec > |----+slf4ec_x86_gcc_withLoc-1.0.0+15.db80236 (Unpacked artifact > copied from cache, content of the "unpack folder" but following the > retrieve pattern) > > Regards, > > Jérémie > > -----Original Message----- > From: Jeremie Faucher-Goulet [mailto: > [email protected]] > Sent: June 29, 2016 4:35 PM > To: [email protected] > Subject: RE: Packaging attribute, unpack location > > 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:[email protected]] > Sent: June 29, 2016 4:16 PM > To: [email protected] > 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 < > [email protected]>: > > > 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:[email protected]] > > > > Jeremie Faucher-Goulet, Jr. Eng. > > Firmware Developer > > Trilliant Inc > > Tel: 450.375.0556 ext. 368 > > [email protected] > > > > www.trilliantinc.com > > > > > > > > > > >
