Nicolas, correct me if I'm misstating something, but I look at an ivy:retrieve-like capability as a nice-to-have but not necessary feature for IvyDE.
IvyDE itself really just exists as a nice convenience, so that classpaths resolve correctly in Eclipse. How it does that--whether with ivy:cachepath or with an ivy:retrieve to a specified directory--is somewhat of an implementation detail in this respect. Either way, the ClassNotFoundExceptions go away. The tool of record is still the build script itself. Once you have IvyDE doing Ivy retrieves to the lib directory that the build script is doing retrieves to, it kind of feels to me like you're letting the IDE (the second-class citizen) encroach into the realm of the build script (the first-class citizen). That concern aside, suppose the developer has blown away their Ivy cache. I don't see why the issue Aaron describes cannot be addressed simply by right-clicking on the Ivy icon in Package Explorer and selecting Resolve. Granted, it takes a little getting used to for developers to get in the habit of this, but this seems like part of the contract of using Ivy. As an Ivy consumer, you need to have some understanding as to when a resolve is necessary. On Fri, Jan 16, 2009 at 1:40 PM, Nicolas Lalevée <[email protected] > wrote: > > Le 16 janv. 09 à 06:25, Yu, Aaron (IT) a écrit : > > > 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. >> > > It seems to me that the way you want to use caching is actually like using > the retrieve job. > The retrieve job would get the dependencies and put it in your project lib > directory (somehow your by-project cache), and the IvyDE would build the > classpath based on the content of that lib directory. > Unfortunately this feature is not implemented yet: > https://issues.apache.org/jira/browse/IVYDE-56 > > Nicolas > >
