RE: Packaging attribute, unpack location
Hello Mark, Thank you for taking the time in confirming what I observed. I had thought about using the "name" instead, but it doesn't play well in my mind. Using a Ivy property to define an artifact name would feel a bit weird to me. I need to use a property because the conf is only resolved at invocation time, either by passing arguments to ant or by environment variable. If I can keep the triplet "org, name and rev" static, that feels much better. I have no doubt it would work, but I don't really like obfuscating my ivy.xml file that much. "Type" sounds like an interesting idea though. I'll have a look on whether I prefer that to using "conf" and doing the unpacking myself. I kinda like the flexibility/control gained by doing the unpacking myself. All I need, in its simplest form, is the following snippet in build.xml: Fundamentally, I believe Ivy should do the unpacking in the same location within it's cache as the file downloaded. In essence, follow the cache pattern too. I might open a ticket on this subject. Best regards, Jérémie -Original Message- From: Marc De Boeck [mailto:mdeb...@gmail.com] Sent: July 5, 2016 3:13 AM To: ivy-user@ant.apache.org Subject: Re: Packaging attribute, unpack location Hello Jérémie, Just to let you know: I did some tests with the packaging attribute, and experienced the same behaviour as you. I found however the following workaround: You can use the type attribute to download the artifacts to different directories in your cache-directory. In your environment this would mean: And then change the artifactPattern of your cache-settings as follows: You can also consider to use the "name" attribute of your artifacts to distinguish your artifacts. In its simpliest case, your ivy-publications section would become: And your cache settings can become something like this: Probably you also have to adapt the layout of your repositories. The latter solution is much simplier and is for me the best way to use Ivy: inside an ivy-module, you have one or more artifacts each with their own unique name (possibly for different configurations). The extra-attributes provide some extra flexibility, but make everything more complex. They can be useful if you want to parse the published ivy.xml by other tools, or if you have to mimic maven behaviour (e.g. by using the e:classifier attribute). Regards, Marc 2016-07-04 21:37 GMT+02:00 Jeremie Faucher-Goulet < jeremie.faucher-gou...@trilliantinc.com>: > Thanks for your feedback Hugh, > > Interesting concept of having a unpack cache to reuse across projects, > I'll keep that in mind as our needs evolve. I'll make this an > iterative process so this could very much prove useful in the mid to long > term... > For now I'll simply use the ant task in my ant file to unpack > from the zip located in the ivy cache to a local folder of the project > using the dependency. But this will probably grow inefficient soon > enough ;) > > Thank you, > > Jérémie > > -Original Message- > From: Greene, Hugh [mailto:hgre...@tmvse.com] > Sent: July 1, 2016 4:58 AM > To: ivy-user@ant.apache.org > Subject: RE: Packaging attribute, unpack location > > Hi Jérémie, > > I have some experience which might be useful to you in your experiments. > > We have a set of Gradle plugins for doing something similar for Ivy > modules with ZIP artifacts. We do the unzipping separately because we > had to (pre-Ivy-2.4) and because we chose to unzip modules to a > separate folder whose location we control. That means that you can > have one such "unpack cache" per volume and symlinks/hardlink the > files into your project workspace, thereby saving disk space if you > have multiple workspaces with an overlapping set of dependencies. > > One subtle mistake we made, and have yet to undo, is that we unzipped > all ZIPs from a module into one folder, even though different > configurations of that module should really only expose the contents > of some subset of those ZIPs. That means you can just symlink the > whole folder, rather than having to somehow "merge" the separate > folders for each configuration. But it means that a folder symlinks > in your workspace may contain more than it should according to your > project's specified dependencies, if you previously unzipped files on > the same machine for a different project with a larger set of configurations > of that module. > > Hope that's useful (and makes sense!), > > Hugh Greene, Senior Software Developer Toshiba Medical Visualization > Systems Europe, Ltd Bonnington Bond, 2 Anderson Place, Edinburgh EH6 > 5NP, UK Tel + 44 (0)131 472 4792 / Fax + 44 > (0) 131 472
RE: Packaging attribute, unpack location
I did some tests with "type". What I've found out is that I need to specify both "conf" and "type" to the same value in my publications, "cortex-m4_gcc_withoutLoc" for example. conf is needed for resolving the dependency (type can't be used with the element). type is needed for allowing different paths during unpacking using cache patterns (unpacking doesn't use conf or extra attributes in cache patterns). Once I do this, I'm able to retrieve the proper artifact. I can even use the same path and filename for the same dependency name within my project as long as my ant task cleans-up the "/lib" folder before calling . If I don't do this, of course I get into the same problem as I had in the cache, having the same folder so Ivy sees no needs to copy-over from cache and keeps the dirty version. I did test the "sync" attributes on the task, but it seems that it too, isn't compatible with unpacking. When set to true, my /lib folder stays empty. I find it a bit redundant having to specify the same value twice within two attributes (type and conf). I guess I could specify a ivy property if I really wanted to avoid it. But even with this little annoyance, I prefer it to unpacking manually as it looks tidier and reduce the amount of scripting and duplication of configuration variables/settings. Best regards, Jérémie -Original Message- From: Jeremie Faucher-Goulet [mailto:jeremie.faucher-gou...@trilliantinc.com] Sent: July 5, 2016 12:52 PM To: ivy-user@ant.apache.org Subject: RE: Packaging attribute, unpack location Hello Mark, Thank you for taking the time in confirming what I observed. I had thought about using the "name" instead, but it doesn't play well in my mind. Using a Ivy property to define an artifact name would feel a bit weird to me. I need to use a property because the conf is only resolved at invocation time, either by passing arguments to ant or by environment variable. If I can keep the triplet "org, name and rev" static, that feels much better. I have no doubt it would work, but I don't really like obfuscating my ivy.xml file that much. "Type" sounds like an interesting idea though. I'll have a look on whether I prefer that to using "conf" and doing the unpacking myself. I kinda like the flexibility/control gained by doing the unpacking myself. All I need, in its simplest form, is the following snippet in build.xml: Fundamentally, I believe Ivy should do the unpacking in the same location within it's cache as the file downloaded. In essence, follow the cache pattern too. I might open a ticket on this subject. Best regards, Jérémie -Original Message- From: Marc De Boeck [mailto:mdeb...@gmail.com] Sent: July 5, 2016 3:13 AM To: ivy-user@ant.apache.org Subject: Re: Packaging attribute, unpack location Hello Jérémie, Just to let you know: I did some tests with the packaging attribute, and experienced the same behaviour as you. I found however the following workaround: You can use the type attribute to download the artifacts to different directories in your cache-directory. In your environment this would mean: And then change the artifactPattern of your cache-settings as follows: You can also consider to use the "name" attribute of your artifacts to distinguish your artifacts. In its simpliest case, your ivy-publications section would become: And your cache settings can become something like this: Probably you also have to adapt the layout of your repositories. The latter solution is much simplier and is for me the best way to use Ivy: inside an ivy-module, you have one or more artifacts each with their own unique name (possibly for different configurations). The extra-attributes provide some extra flexibility, but make everything more complex. They can be useful if you want to parse the published ivy.xml by other tools, or if you have to mimic maven behaviour (e.g. by using the e:classifier attribute). Regards, Marc 2016-07-04 21:37 GMT+02:00 Jeremie Faucher-Goulet < jeremie.faucher-gou...@trilliantinc.com>: > Thanks for your feedback Hugh, > > Interesting concept of having a unpack cache to reuse across projects, > I'll keep that in mind as our needs evolve. I'll make this an > iterative process so this could very much prove useful in the mid to long > term... > For now I'll simply use the ant task in my ant file to unpack > from the zip located in the ivy cache to a local folder of the project > using the dependency. But this will probably grow inefficient soon > enough ;) > > Thank you, > > Jérémie > > -Original Message- > From: Greene, Hugh [mailto:hgre...@tmvse.com] > Sent: July 1, 2016 4:58 AM > To:
