The mail of Jeremy raise a question: How do we support extension of ivy? I see different approaches. More than one is probably valid, and the choice will certainly have to be done on a case by case basis. But deciding some a-priori guidelines could help the future choice.
Here are the approaches that I see: 1. Having a separate project outside apache and maintain the extension there. 2. Having a 'sandbox' project inside apache and maintain the extension there. 3. Incorporate the extension into the ivy project itself. 4. Same as 3. But incorporate also the contributor as a committer. The pros/cons I see for each approach are: - 1. is nice when there are license issue. It is easer to put in place. However, the risk of non maintenance is bigger. Also, it is more difficult for the developer of those extensions to keep their motivation when their project is +/- disconnected from the rest of the ivy community. - I don't know if the approach 2 is possible for a project under incubation. I guess not. - The approach 3 requires that the current set of committer have the ability to maintain the extension. We should also check that there is no license issue. - The approach 4 requires that the contributor is 'trusted' by the community. WDYT? Gilles > -----Original Message----- > From: Jeremy Handcock [mailto:[EMAIL PROTECTED] > Sent: mardi 22 mai 2007 6:50 > To: [email protected] > Subject: Ivy repository and resolver for Amazon's S3 service > > Hi there, > > I've recently developed an Ivy repository and resolver that allows you > to store and resolve Ivy artifacts/metadata using Amazon's S3 service > [1]. Is there any interest in having this become part of the Ivy core? > Is there some kind of Ivy extensions project that this might fit better > under? > > Thanks, > > Jeremy > > [1] http://s3.amazonaws.com
