Re[6]: confusing artifacts retrieving

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