ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremie Faucher-Goulet <Jeremie.Faucher-Gou...@trilliantinc.com>
Subject RE: Packaging attribute, unpack location
Date Wed, 29 Jun 2016 20:34:34 GMT
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:mdeboec@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-Goulet@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-goulet@trilliantinc.com
>
> www.trilliantinc.com
>
>
>
>
>
Mime
View raw message