ivy.original.xml file using artifact pattern in cache and causing problems
--------------------------------------------------------------------------
Key: IVY-787
URL: https://issues.apache.org/jira/browse/IVY-787
Project: Ivy
Issue Type: Bug
Reporter: Shawn Castrianni
> 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]/[artifa
> ct].[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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
