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 Thu, 30 Jun 2016 17:58:52 GMT
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:mdeboec@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-Goulet@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-Goulet@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: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