On Jan 4, 2008 10:15 PM, Jason Trump <[EMAIL PROTECTED]> wrote:
> New feature suggestion (obviously not for 2.0): allow some kind of
> optional ivy settings file on the ivy repository. This would allow for less
> configuration on the ivy client side, and make it easier to update the
> structure
On Jan 4, 2008 4:46 PM, Gilles Scokart <[EMAIL PROTECTED]> wrote:
> I have the feeling the checkModified, the changingPattern and the
> changingMatcher are more a property of the remote
> repository (the way the repository is build) than a property of the local
> cache (the way one particular user
On Jan 4, 2008 11:42 PM, Maarten Coene <[EMAIL PROTECTED]> wrote:
> Xavier,
>
> why did you change the way the attributes are processed in the
> XmlSettingsParser class?
>
> For instance, before your commit, it was like this:
> String propFilePath = ivy.substitute((String) attributes.get("file"));
Xavier,
why did you change the way the attributes are processed in the
XmlSettingsParser class?
For instance, before your commit, it was like this:
String propFilePath = ivy.substitute((String) attributes.get("file"));
After your commit, it is like this:
String propFilePath = (String) attributes
New feature suggestion (obviously not for 2.0): allow some kind of optional
ivy settings file on the ivy repository. This would allow for less
configuration on the ivy client side, and make it easier to update the
structure of your ivy repository. Things that could go in this file:
* artifa
Hi
this change was intentional, a bugrep was filed that under certain
circumstances the generated file name was used before it was created,
which could indeed not be ruled out. For situations where only a name is
needed the method createTempFileName was introduced.
I see your problem and hav
Seems like checkModified / changingPattern / changingMatcher all change local
cache behavior in response to a particular remote repository. So the structure
comes from the rep, but the behavior is all about the cache. I think it might
be clearer what these properties do if they are moved to ca
I have the feeling the checkModified, the changingPattern and the
changingMatcher are more a property of the remote
repository (the way the repository is build) than a property of the local cache
(the way one particular user want to
cache the files).
WDYT?
Gilles
> -Original Message-
>
On Dec 28, 2007 1:29 AM, Xavier Hanin <[EMAIL PROTECTED]> wrote:
> One thing I'd still like to change in this area besides the fix and
> improvement in flexibility is to make repository cache managers responsible
> for managing the useOrigin flag. It would be much more consistent IMO, and
> also m
+1
Gilles
> -Original Message-
> From: Xavier Hanin [mailto:[EMAIL PROTECTED]
> Sent: vendredi 4 janvier 2008 14:56
> To: Ant Developers List
> Subject: Re: flexible cache management (IVY-399)
>
> After more thoughts and while starting documenting the new cache management,
> I think I h
After more thoughts and while starting documenting the new cache management,
I think I have a better alternative to my last proposition:
- put any defaults related to repository cache managers in the caches
element. This include the default cache manager to use, the default basedir
(for repository
11 matches
Mail list logo
