ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Castrianni <>
Subject RE: Re[2]: confusing artifacts retrieving
Date Wed, 19 Mar 2008 17:20:17 GMT
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 []
Sent: Wednesday, March 19, 2008 11:58 AM
To: Brown, Carlton
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

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

What I am trying to achieve is to use Ant-like pattern for artifacts

Pavel Sher
Software Developer
JetBrains, Inc.
"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
>, 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.

View raw message