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