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