ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: ivy.original.xml cache bug?
Date Sun, 30 Mar 2008 21:27:59 GMT
On Sun, Mar 30, 2008 at 8:23 PM, Shawn Castrianni <
Shawn.Castrianni@halliburton.com> wrote:

> I have a caches tag like this:
>
>                <caches defaultCacheDir="${ivy.cacheDir.root}/${
> env.CACHE_DIR}-${env.BUILD_REVISION}" ivyPattern="${lgcbuild.releaseName}/[module]/[branch]/[revision]/[type]/[artifact].[ext]"
> artifactPattern="${lgcbuild.releaseName
> }/[module]/[branch]/[revision]/[type]/[home]/[homeType]/[path]/[artifact].[ext]"/>
>
> which includes my custom attributes of [home], [homeType], and [path].  In
> my ivy.xml files, some of these custom attributes are filled out and some
> are left as empty strings.  The empty strings allow them to be ignored when
> used as directories.  Everything seems to work fine for the publish,
> resolve, and retrieve.  However, my cache is not quite right.  The ivy.xmlis properly
using the ivyPattern above in my caches tag, however, there is
> some other ivy.original.xml file that seems to be using the
> artifactPattern.  Because it is using the artifactPattern AND there is no
> value at all for my custom attributes (not even an empty string), the cache
> is placing the ivy.original.xml file into subdirectories with "[home]",
> "[homeType]", and "[path]" as names.  This ivy.original.xml file is
> probably a new file as a result of an enhancement recently implemented in
> IVY 2 to retain original dependency information.

Let's say it's part of the change in cache management, now we cache the
module descriptor exactly as downloaded, before storing it in ivy format
(when you use a pom the difference is more obvious).


>
> Regardless, I would think the ivy.original.xml file should probably also
> use the ivyPattern in the cache and not the artifactPattern??

The problem is that people may not use the [artifact] token in ivy cache
pattern, and since we use this token to make the difference between the
original file and the converted one, we could run into name collisions in
this case. But maybe using the artifact token is not a good idea, maybe we
should try to append a suffix to the ivy file path instead (like .original).
Please open an issue about this problem, and we'll see what's the best
option to solve the problem considering what I just said.

Xavier

>
>
> ---
> Shawn Castrianni
>
> ----------------------------------------------------------------------
> 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/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message