on 11/25/2000 7:25 AM, "Conor MacNeill" <[EMAIL PROTECTED]> wrote:
> OK, I like this idea. Rather than duplicate jars into every project, it > allows each project to go and fetch the jars where necessary, from where > they live. More like a web. Well, more like CPAN. > We wouldn't need to redistribute anyway, since such a task could > conceivably go to the actual home of each jar. For example, why > duplicate junit.jar on jakarta.apache.org when it is available from > junit.org. I think that where a jar is not available as a "direct" > download, such as JMX, taht is whenwe would need to display the > "permission" message. The issue is that you simply need just the .jar. Nearly all of the sites I know of don't provide a link to just the .jar. You would then need to encode information to be able to extract the .jar from a .zip or .tar.gz and then deal with it. That could be a serious pain in the ass. > But ant could bootstrap in the components needed for the optional tasks, > such as junit. Right, but not Ant itself. :-) > I'm certainly interested. I see this as a sort of distributed package > manager. Rather than an allfiles.xml, I would see each "product" having > its own file. When the <jpan> task processes that description, it would > download the files of the other products upon which it depends. Right, but then you would have to hit the server multiple times for all of the dependencies. I'm trying to lower that amount as this could become HUGE and you don't want scalability issues. :-) One thing we could also do is .gz the allfiles.xml so that it is even compressed. Text compresses very nicely. :-) We could even add a caching routine so that it would simply do a HEAD request on the HTTP server to find out the last modified version of the file and keep a cache of the file locally instead of having to download it each time. > jpan may have to be interactive. Just kicking around a few ideas :-) Exactly. :-) -jon -- twice of not very much is still a lot more than not very much
