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
>
>
>
>
>
