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: Using cache patterns (IVY-717)
Date Thu, 21 Feb 2008 19:23:52 GMT
On Thu, Feb 14, 2008 at 8:38 PM, Ivan Rambius Ivanov <
rambiusparkisanius@yahoo.com> wrote:

> Hello,
>
> I am trying to use cache patterns to organize the ivy
> cache by branches and I observed some strange
> behavior.
>
> I have the following settings:
>
> <settings defaultResolver="http-resolver"
>  defaultBranch="${ivy.branch}"
> cacheIvyPattern="[organisation]/[branch]/[module]/ivy-[revision].xml"
>
>
> cacheArtifactPattern="[organisation]/[branch]/[module]/[type]s/[artifact]-[revision].[ext]"/>
>
> The ivy.xml's and the artifacts are correctly
> downloaded to directories named after the branches.
> However, some properties files still stored in
> directories following the default patterns. The
> locations of these properties files are
> [organisation]/[module]/ivydata-[revision].properties.
>
> Is this a bug or a feature?
>
> I would assume that the location of those ivydata
> files should follow the cache patterns defined in
> <settings>.
> Can you point where in the ivy code I could change it?

The problem is in org.apache.ivy.core.cache.DefaultRepositoryCacheManager.

This class use a third pattern for properties file, defined with a constant:
DEFAULT_DATA_FILE_PATTERN

You can change the value of this pattern programmatically with
setDataFilePattern, but we have no support for changing it from the
settings.

Maybe the best solution would be to replace Ivy cache pattern:
[organisation]/[module]/ivy-[revision].xml
by:
[organisation]/[module]/[artifact]-[revision].[ext]

And then use the same pattern for properties and ivy file, with different
values for [artifact] and [ext]. The problem is that it would break with
people who change the ivy pattern with hardcoded artifact name and
extension.

But since we are changing the cache management deeply in Ivy 2, I don't see
this as a big issue if we document it properly. We could even test such a
case and add a .properties suffix in that case, to make such settings work
with a warning.

Could you please open an issue in JIRA about that?

Xavier

>
>
> Thank you in advance.
>
> Regards
> Rambius
>
>
> Tangra Mega Rock: http://www.radiotangra.com/
>
>
>
>  ____________________________________________________________________________________
> Be a better friend, newshound, and
> know-it-all with Yahoo! Mobile.  Try it now.
> http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>
>


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