On Fri, 4 May 2007, Xavier Hanin <[EMAIL PROTECTED]> wrote: > On 5/4/07, Stefan Bodewig <[EMAIL PROTECTED]> wrote: >> On Fri, 04 May 2007, Steve Loughran <[EMAIL PROTECTED]> wrote:
>> > we'd need a metadata tree mapping antlibs to well known packages, >> > but that is not too hard. JSON, perhaps. >> >> Not sure. Who'd maintain it? Maintaining it for our own Antlibs >> is easy, but we wouldn't want the mechanism to only apply for them. >> And I'd be scared of the security implications of a Wiki driven >> list or something even close to that. > > You make a good point. So maybe this would require all information > (module identifier and version) to be in the antlib URL, thus > requiring another antlib url format (maybe with a distinct > protocol), which is not really going in the same direction as you > suggested, steve. At least that would allow us to live without a central URI -> antlib artifact mapping, I'd prefer that. > Another option from the top of my head: build a module identifier > from the package name, even if it's not very accurate, the only > purpose is to get something unique. It could something like: org = > package name; module = last part of the package name eg: > org.apache.ivy.ant => org = org.apache.ivy.ant; module = ant This > module would not be the antlib module, but only a module with its > only artifact being metadata about the module containing the actual > antlib. This metadata could be in a simple format, JSON, XML or > properties file. Then we can use this metadata to actually download > the antlib. The remaining problem is version information. That would require an extra level of indirection. I think I'm more leaning towards a different URI scheme that encoded all information that we need (including version). Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
