ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin (JIRA)" <j...@apache.org>
Subject [jira] Updated: (IVY-321) advanced cache cleaning
Date Thu, 06 Dec 2007 14:18:43 GMT

     [ https://issues.apache.org/jira/browse/IVY-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Xavier Hanin updated IVY-321:
-----------------------------

    Description: 
Ivy should provide some solution to manage the size of the cache.  Ivy settings should have
some rules saying how long to keep versions of the jars in the cache.  Theses rules could
be parametrized in function of the module, of the type of revision, of the age of the files
or depending of the last time it has been used, the existence of dependent modules, etc. 
(I let you choose the best solutions)

The cleaning might be performed automatically when a resolve is performed, or might be invocable
from a dedicated task.

There is currently no easy way to perform similar cleaning.  


To illustrate this need, here is a mail I received from a developer who is using ivy since
1 day. He has wriiten an ant scripts launching some tests build by our continuous build.

{quote}
Gilles,
 
The build file is working great, so thanks for that! It's a very easy way to distribute software
to the testers (until now I had to send all the jars and update them manually etc)
 
However, one minor issue: I've noticed that ivy keeps all version in its cache. After just
a day of playing around with it I already got a cache of almost 100MB, so this will get out
of control rather quickly. Is there a configuration option somewhere to limit the cache size?
or to automatically delete older versions? Even if it just leaves the latest version I'm ok
with that, although it might be neat to leave the last 3 or 5 or something.
  
Peter
{quote}

  was:
Ivy should provide some solution to manage the size of the cache (and of repositories).  Ivy
configuration should have some rules saying how long to keep versions of the jars in the cache.
 Theses rules could be parametrized in function of the module, of the type of revision, of
the age of the files or depending of the last time it has been used, the existence of dependent
modules, etc.  (I let you choose the best solutions)

The same kind of things should also exist for a reposiotry (mainly for continuous build repository).

The cleaning might be performed automatically when a retrieve (for the cache) or a publish
(for a repository) is performed, or might be invocable from a dedicated task.

There is currently no easy way to perform similar cleaning.  


To illustrate this need, here is a mail I received from a developper who is using ivy since
1 day. He have wriiten an ant scripts launching some tests build by our continuous build.

{quote}
Gilles,
 
The build file is working great, so thanks for that! It's a very easy way to distribute software
to the testers (until now I had to send all the jars and update them manually etc)
 
However, one minor issue: I've noticed that ivy keeps all version in its cache. After just
a day of playing around with it I already got a cache of almost 100MB, so this will get out
of control rather quickly. Is there a configuration option somewhere to limit the cache size?
or to automatically delete older versions? Even if it just leaves the latest version I'm ok
with that, although it might be neat to leave the last 3 or 5 or something.
  
Peter
{quote}

        Summary: advanced cache cleaning  (was: cache and repository cleaning)

> advanced cache cleaning
> -----------------------
>
>                 Key: IVY-321
>                 URL: https://issues.apache.org/jira/browse/IVY-321
>             Project: Ivy
>          Issue Type: New Feature
>            Reporter: Gilles Scokart
>            Assignee: Xavier Hanin
>
> Ivy should provide some solution to manage the size of the cache.  Ivy settings should
have some rules saying how long to keep versions of the jars in the cache.  Theses rules could
be parametrized in function of the module, of the type of revision, of the age of the files
or depending of the last time it has been used, the existence of dependent modules, etc. 
(I let you choose the best solutions)
> The cleaning might be performed automatically when a resolve is performed, or might be
invocable from a dedicated task.
> There is currently no easy way to perform similar cleaning.  
> To illustrate this need, here is a mail I received from a developer who is using ivy
since 1 day. He has wriiten an ant scripts launching some tests build by our continuous build.
> {quote}
> Gilles,
>  
> The build file is working great, so thanks for that! It's a very easy way to distribute
software to the testers (until now I had to send all the jars and update them manually etc)
>  
> However, one minor issue: I've noticed that ivy keeps all version in its cache. After
just a day of playing around with it I already got a cache of almost 100MB, so this will get
out of control rather quickly. Is there a configuration option somewhere to limit the cache
size? or to automatically delete older versions? Even if it just leaves the latest version
I'm ok with that, although it might be neat to leave the last 3 or 5 or something.
>   
> Peter
> {quote}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message