Ivy NextGen requirements
What is this page about?
This page is a collaboration board for the Ivy development community. Here we organize the ideas we have about how Ivy should look like in the future and what features we want to see in it.
The page would be updated frequently, according to the activity in the ivy-dev mail list.
Current ideas for future Ivy release
(created: Nov 14, 2006)
1. Ivy should well define an artifact metadata format. It would be based on Ivy 1.x and Maven POM formats. (TODO: this issue is to be extended and detailed.)
2. Ivy would define and use a set of rules about artifact naming and identification.
3. Ivy would publish a public metadata repository (perhaps an extension to the current ivyrep.org site). This repository would make use of the naming conventions as defined in (2) above.
4. Ivy would be able to access local and remote repositories in a pluggable way. (TODO: define the API: what operations a repository-resolver should have)
5. Ivy would use pluggable latest-strategy modules. The latest-strategy have to choose a specific revision among many revisions of the same artifact according to user request. For example: the common use is to choose the "latest" revision according to a given status (integration, milestone or release) and according to revision and time. (TODO: define API operations)
6. Ivy output should be handled in a pluggable manner. It should be simple to replace the default output messages with a quieter outputter.
7. Ivy needs to have a mechanism to invalidate the cache from an Ant Task / API. There should never be a reason for someone to manually have to remove ~/.ivy (or equivalent)
8. Ivy needs to have an option to allow for better cache consistency, this may be slower for some kinds of resolvers - but it optional and users who need a consistent cache can get one
... to be continued...