ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daffin, Miles \(IDEAS\)" <Miles.Daf...@morganstanley.com>
Subject FW: IvyDE cache location
Date Fri, 30 Jan 2009 09:15:40 GMT
Maarten,

Thanks, we will have a look at this.

Miles

-----Original Message-----
From: Maarten Coene [mailto:maarten_coene@yahoo.com]
Sent: 29 January 2009 22:06
To: ivy-user@ant.apache.org
Subject: Re: IvyDE cache location

Maybe you could use the cache attribute on your resolvers pointing to different caches?
Cfr http://ant.apache.org/ivy/history/latest-release/settings/resolvers.html#common

Would that help?

Maarten

----- Original Message ----
From: "Daffin, Miles (IDEAS)" <Miles.Daffin@morganstanley.com>
To: mgitman@gmail.com; ivy-user@ant.apache.org
Cc: "Yu, Aaron (IDEAS)" <Fan.Yu@MorganStanley.com>; "Sinclair, Jeffrey (IDEAS)" <Jeffrey.Sinclair@morganstanley.com>
Sent: Thursday, January 29, 2009 7:41:28 PM
Subject: RE: IvyDE cache location

Hi Mitch,

Aaron is on holiday at the moment. Let me chip in with some more information. I think we have
a legitimate problem with the cache but I am now pretty certain that the ability to set project
or workspace specific cache locations will not solve it.

I have asked our developers again why they thought the global cache was a bad idea. It seems
that there is a problem when different repositories contain dependencies with the same org,
name and rev but with differing ivy metadata. If ivy finds the resolved metadata for an org/name/rev
in the cache it seems it will just use it - in some cases wrongly.

Is there a way of adding an extra layer to the cache to that cached stuff is segregated according
to which repository it came from?

Thanks,

Miles Daffin
Morgan Stanley | IDEAS PRACTICE AREAS
20 Cabot Square | Canary Wharf | Floor 01 London, E14 4QW
Phone: +44 20 7677-5119
Fax: +44 20 7056-4572
Miles.Daffin@morganstanley.com

-----Original Message-----
From: Mitch Gitman [mailto:             ]
Sent: Friday, January 16, 2009 1:42 PM
To: ivy-user@ant.apache.org
Subject: Re: IvyDE cache location

If you want to give each individual developer the ability to customize the location of their
Ivy cache, one approach is to add the following line to your global ivysettings.xml:
<include file="${ivy.default.ivy.user.dir}/ivysettings.xml"/>

Then the user can define their own Ivy settings to their heart's content in USER_HOME/.ivy2/ivysettings.xml.
Note: if you do this, this local Ivy settings file will be required.

Now, if your concern is doing ivy:cleancache for one project and then cleaning out the whole
cache, one way to do this is by establishing namespaces for different projects. I don't have
the details on that handy.

However, I don't quite see how clearing the Ivy cache would "crash the building of other projects."
If you do ivy:cleancache on one project or just manually delete your USER_HOME/.ivy2/cache
(or whatever you customize it to), the only complication this should introduce is the extra
wait that comes with the re-downloading of the dependent modules on the next Ivy resolve.
So, unless I'm misunderstanding something, it kinda seems like you're going to a lot of trouble
to address a non-issue.

On Thu, Jan 15, 2009 at 9:25 PM, Yu, Aaron (IT) <Fan.Yu@morganstanley.com>wrote:

> Hi,
>
> I have a problem of using Ivy and IvyDE.
> At my firm we are in the process of switching to Ivy for managing our
> java dependencies. We do not want thousands of developers to resolve
> dependencies in  different  ways so we provide a centralized ,
> read-only ivy-settings.xml file  which is used by all developers.
> However, this presents us with a problem. We would like to  make it
> possible for our users to set their own cache locations, because if
> they  use the same cache location for all projects, when  they clean
> the cache in one project, the whole cache location will be cleaned,
> and this  will crash the building of other projects.
>
> I know we can create a project-specific ivy-settings.xml file, and use
> 'defaultCacheDir', 'resolutionCacheDir' and 'repositoryCacheDir'
> attributes in 'caches' element to set the project-based cache location.
> But as I mentioned above, to make all the projects more manageable and
> shareable, we do not encourage developers to have the project-specific
> ivy setting file.
>
> To get around this we have implemented a new properties page for the
> ivyde plugin under the existing one called simply 'Cache'. This allows
> a user to choose the cache location. The choices are: Default
> ($HOME/.ivy2) and Workspace (workspace_dir/.metadata/.ivy2). We then
> reset the ivy.home System property and trigger re-resolution of all
> project ivy classpath containers when the users changes this setting
> (the change affects all projects in the workspace since ivy core reads
> the ivy.home System property to find out where it should do its
> caching). However, we are now wondering if what is really needed is a
> private cache area for each project in the workspace, for example:
> workspace_dir/.metadata/.ivy2/project_name. But this is not possible
> at the moment due to the way in which ivy core decided where to place
> its cache. (And, as we said, we do not want users to have to specify
> their own ivy-settings for each project for this reason alone.)
>
> Other people at our firm have also pointed out that it might be better
> if ivy core used a version specific cache location by default since
> there could be differences in cache metadata between versions. This
> would cause cache corruption if different versions of ivy core were
> run on the same system.
>
> All this seems to indicate that the subject of caching needs
> rethinking in ivy core and ivyde, and we would like to ask for some
> suggestions on this.
>
> Thanks!
>
> Aaron Yu
> Morgan Stanley | Technology
> 222 Yan An Road (East)
> 200002 Shanghai
> Phone: +86 21 2321-2106
> Fan.Yu@MorganStanley.com
> --------------------------------------------------------
>
> NOTICE: If received in error, please destroy and notify sender. Sender
> does not intend to waive confidentiality or privilege. Use of this
> email is prohibited when received in error.
>
--------------------------------------------------------

NOTICE: If received in error, please destroy and notify sender. Sender does not intend to
waive confidentiality or privilege. Use of this email is prohibited when received in error.
--------------------------------------------------------

NOTICE: If received in error, please destroy and notify sender. Sender does not intend to
waive confidentiality or privilege. Use of this email is prohibited when received in error.

Mime
View raw message