Hello Shawn, > 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. This is interesting feature, but when I tried this, I realized that Ivy matcher does not try to match such attributes values. So if I store directory structure in custom attribute I won't be able to match against it. > 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. Again, what about Ivy matcher? I need to match against directory structure and it seems configurations won't help me too. For me it looks like in most cases Ivy users do prepare artifacts before publishing to the repository, i.e. artifacts structure is configured to simplify artifacts retrieval. But in my case it does not work either. When someone publishes artifacts he often cannot imagine what is the best structure for others when they retrieve these artifacts. For example, someone published: dist/Release/a.exe dist/Release/b.exe dist/Release/c.exe And in another build I want simple thing: download all .exe files but without dist/Release folders and it turns out that the only way to do this is to modify ivy.xml file describing published artifacts, but I do not have enough rights to do this (not to mention that in my case this file is generated automatically and it cannot be generated in different formats for different users). Now I see only one workaround. I can resolve files with help of Ivy (I'll continue storing directory structure in artifact name) and then I have to write custom retrieve process which will get artifacts from Ivy cache and create corresponding directory structure depending on the pattern used to resolve artifacts. Of course it is far from ideal, I would prefer to customize Ivy then to write my own retreive task. -- Pavel Sher Software Developer JetBrains, Inc. http://www.jetbrains.com "Develop with pleasure!" > --- > 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.
