I specify my directory structure in the pattern on my ivy:retrieve ant task. However, you can only use one pattern for all artifacts. Therefore, if you want more control over which artifacts go to which directories, you have 2 choices:
1. Create your own extended properties and use them in your retrieve pattern. For example, I have created my own attribute called platform which I set in my ivy.xml so that I can specify that .dll artifacts are for platform="win32" and .so artifacts are for platform="linux32". Then my retrieve pattern uses [platform] as part of the directory structure causing the .so's to go to a linux32 directory and .dll's to go to a win32 directory. One thing to note here is that if you set the platform="" (the empty string) in the ivy.xml file, then that artifact will be retrieved ignoring the [platform] directory. 2. Divide up your artifacts in your ivy.xml into different configurations. Then you can make multiple calls to retrieve, each with its own configuration setting and its own retrieve pattern. Therefore, all artifacts from one configuration would go to one directory location specified by the retrieve pattern and all other artifacts from a different configuration would go to a different directory location specified by a different retrieve pattern. --- Shawn Castrianni -----Original Message----- From: Pavel Sher [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 19, 2008 11:58 AM To: Brown, Carlton Cc: [email protected] Subject: Re[2]: confusing artifacts retrieving Hello Carlton, ivy.xml in such form is generated by the server (TeamCity). When we implemented ivy integration for the first time we decided to choose this format because it looked natural. Now server generates file where all artifacts (published by a build) are listed with their directory structure. If I understand you right I should probably use some logical names for artifacts and encode directory structure in some other place (for example, in organization). It is possible but it does not solve my problem because I cannot affect the way how Ivy creates destination folders. What I am trying to achieve is to use Ant-like pattern for artifacts downloading. -- Pavel Sher Software Developer JetBrains, Inc. http://www.jetbrains.com "Develop with pleasure!" > This is just my opinion... I think your ivy file is structured in a way > that defeats the purpose of Ivy. The ivy.xml file should only contain > abstract descriptions of the artifact, not concrete references to how > the storage is implemented. For example, it would be difficult to > convert this to a relational database or some other storage > implementation. > If you insist on having this directory structure in your repository, > then you probably want to split this ivy file into 3 components, and use > the organisation attributes appropriately, like: organisation="file1", > organisation="file1.file2.file3" in each ivy file respectively. > If you can be flexible on the directory structure, you can still achieve > some segregation by using Ivy configurations appropriately. I find > configurations useful in situations where there is an unusual layout and > no flexibility to change it. > I do think Ivy could be somewhat improved in how the organisation is > parsed during retrieve. I notice that when doing a retrieve, an > organisation with dotted notation does not get mapped into directories. > For example, given an artifact mine.jar in organisation > org.brown.software, I'd like to see the retrieval of > '[organisation]/[artifact].[ext]' create a local directory structure > org/brown/software/mine.jar. This happens when you publish to a maven > compatible repository, but it doesn't seem to happen when you retrieve > (unless I missed something somewhere). Xavier, is this reasonable > behavior to request, or did I miss the documentation somewhere? > ----------------------------------------- > ==================================================== > This message contains PRIVILEGED and CONFIDENTIAL > information that is intended only for use by the > named recipient. If you are not the named recipient, > any disclosure, dissemination, or action based on > the contents of this message is prohibited. In such > case please notify us and destroy and delete all > copies of this transmission. Thank you. > ==================================================== ---------------------------------------------------------------------- This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.
