Thank you Marc for your sanity check, As I'm brand new to Ivy and experimenting with it, there's always this nagging doubt I made a stupid mistake somewhere ;-) We're working on putting together a new CI and CD process for embedded software projects, and Ivy could prove to be a major part of it.
I only just noticed that the "packaging" attribute is something new, only introduced in Ivy 2.4, so I'm probably experimenting with features that don't have a widespread usage currently. Thanks for your help, Jérémie -----Original Message----- From: Marc De Boeck [mailto:mdeb...@gmail.com] Sent: June 30, 2016 9:29 AM To: ivy-user@ant.apache.org Subject: Re: Packaging attribute, unpack location 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 < jeremie.faucher-gou...@trilliantinc.com>: > 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: > jeremie.faucher-gou...@trilliantinc.com] > Sent: June 29, 2016 4:35 PM > To: ivy-user@ant.apache.org > 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: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 > > > > > > > > > > >
