Conor MacNeill <[EMAIL PROTECTED]> wrote: > I don't think the "available" approach is going to work. It relies > on the classes being in the classpath, but version conflict is one > of the problems cjan seeks to address. I think it is going to need a > repository in which it tracks information about what products and > (potentially conflicting) versions have been installed.
Well, the "available" approach could use a custom classloader that contains those jars. I'm still not sure that having a repository will work out that well, you'd need two repositories at least, one for things installed for the whole system and one for the things a user has installed in his/her private workspace. I'm less concerned with companies - here the system administrators should be willing to install everything the developers need - but with universities and similiar organizations. And then you'd need a way to tell CJAN to add something to the repository that has allready been there before CJAN came into the game. > 1. To what type of user is cjan aimed? Is it > a) the CVS developer, > b) the source distribution user, > c) the binary distribution user guess it's all of them - unless you want to end up holding required JARs within CVS or ship them with distributions. > 2. How pervasive/invasive should cjan become? Can it be a > requirement for a product to launch? Too launch or to build? I think Jose Alberto's distinction is important. But I can imagine you'd require it for both, just not from the start, let CJAN grow. > 3. What are the goals - simple automated downloads of support jars > for a single product - no attempt to worry about managing the > mismatch of versions across a system. Or should it be a package > management system which reports, or even tries to resolve, version > conflicts? My take would be: all of them, one after the other. Stefan
