You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Pavel Sher <Pa...@jetbrains.com> on 2008/03/19 17:58:08 UTC
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.
> ====================================================
RE: Re[2]: confusing artifacts retrieving
Posted by "Brown, Carlton" <Ca...@compucredit.com>.
Mistake in my example... Organisation attribute should be dotted
notation, like this:
<ivy-module version="1.4">
<info organisation="dir1.dir2" module="file3" revision="1.1"/>
<publications>
<artifact name="file3" type="txt" ext="txt"/>
</publications>
</ivy-module>
If you use m2compatible attribute on your resolver then it will get
expanded to dir1/dir2 when you publish it. (but this doesn't happen for
me when I retrieve it, which seems like a bug unless I'm doing something
wrong).
-----------------------------------------
====================================================
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.
====================================================
Re[6]: confusing artifacts retrieving
Posted by Pavel Sher <Pa...@jetbrains.com>.
Hello Xavier,
Thank you for your response, and for your recomendations. I will
submit a feature request to your JIRA.
--
Pavel Sher
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
> Directory structure shouldn't be part of artifacts' names. As others said,
> this would better fit in custom attributes so that you can control your
> paths using Ivy patterns feature, which much better fit Ivy philosophy.
> Trying to transform an attribute in a pattern is not something I like. We do
> it only for maven 2 compatibility, when we convert dots in slashes in
> organization names. Still I suggest to open an issue, and if others share
> the same point of view in the usefulness of this feature, then it would
> probably make sense to introduce a new point of flexibility.
> Xavier
>>
>> --
>> Pavel Sher
>> Software Developer
>> JetBrains, Inc.
>> http://www.jetbrains.com
>> "Develop with pleasure!"
>>
>>
>>
>> > ---
>> > Shawn Castrianni
>>
>>
>> > -----Original Message-----
>> > From: Pavel Sher [mailto:Pavel.Sher@jetbrains.com]
>> > Sent: Wednesday, March 19, 2008 11:58 AM
>> > To: Brown, Carlton
>> > Cc: ivy-user@ant.apache.org
>> > 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.
>>
>>
>>
>>
>>
Re: Re[4]: confusing artifacts retrieving
Posted by Xavier Hanin <xa...@gmail.com>.
On Thu, Mar 20, 2008 at 2:35 PM, Pavel Sher <Pa...@jetbrains.com>
wrote:
> 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.
Directory structure shouldn't be part of artifacts' names. As others said,
this would better fit in custom attributes so that you can control your
paths using Ivy patterns feature, which much better fit Ivy philosophy.
Trying to transform an attribute in a pattern is not something I like. We do
it only for maven 2 compatibility, when we convert dots in slashes in
organization names. Still I suggest to open an issue, and if others share
the same point of view in the usefulness of this feature, then it would
probably make sense to introduce a new point of flexibility.
Xavier
>
> --
> Pavel Sher
> Software Developer
> JetBrains, Inc.
> http://www.jetbrains.com
> "Develop with pleasure!"
>
>
>
> > ---
> > Shawn Castrianni
>
>
> > -----Original Message-----
> > From: Pavel Sher [mailto:Pavel.Sher@jetbrains.com]
> > Sent: Wednesday, March 19, 2008 11:58 AM
> > To: Brown, Carlton
> > Cc: ivy-user@ant.apache.org
> > 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.
>
>
>
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re[4]: confusing artifacts retrieving
Posted by Pavel Sher <Pa...@jetbrains.com>.
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:Pavel.Sher@jetbrains.com]
> Sent: Wednesday, March 19, 2008 11:58 AM
> To: Brown, Carlton
> Cc: ivy-user@ant.apache.org
> 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.
RE: Re[2]: confusing artifacts retrieving
Posted by Shawn Castrianni <Sh...@halliburton.com>.
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:Pavel.Sher@jetbrains.com]
Sent: Wednesday, March 19, 2008 11:58 AM
To: Brown, Carlton
Cc: ivy-user@ant.apache.org
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.
RE: Re[2]: confusing artifacts retrieving
Posted by "Brown, Carlton" <Ca...@compucredit.com>.
> -----Original Message-----
> From: Pavel Sher [mailto:Pavel.Sher@jetbrains.com]
> Sent: Wednesday, March 19, 2008 12:58 PM
> To: Brown, Carlton
> Cc: ivy-user@ant.apache.org
> 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.
Sure you can. If you refactor the ivy.xml to separate it into one
ivy.xml for each level of nesting, then you can use the artifact pattern
to flatten the retrieval.
This was your original example:
<ivy-module version="1.4">
<info organisation="xxx" module="yyy" revision="1.1"/>
<publications>
<artifact name="file1" type="txt" ext="txt"/>
<artifact name="dir1/file2" type="txt" ext="txt"/>
<artifact name="dir1/dir2/file3" type="txt" ext="txt"/>
</publications>
</ivy-module>
Split it into discrete ivy.xml files. The third one may look like this:
<ivy-module version="1.4">
<info organisation="dir1/dir2" module="file3" revision="1.1"/>
<publications>
<artifact name="file3" type="txt" ext="txt"/>
</publications>
</ivy-module>
Now you can flatten the destination directory, and you don't need to
reorganize your repository:
<ivy:retrieve pattern="lib-retrieved/[artifact].[ext]" type="ext"/>
The result will be lib-retrieved/file3.txt which is what you wanted.
At this point you have to decide whether your client implementation will
do resolve+retrieve 3 times (one for each ivy.xml file), or alternately
set up the dependency relationships so that you can do it transitively
with one single resolve + retrieve. This way you can avoid writing a
bunch of Ant goop to hold everything together. At least that's how I
understand your situation.
-----------------------------------------
====================================================
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.
====================================================