Niclas Hedhman wrote:
am -1 for directly handling classloading.
Then please provide an answer to the question;
How do you intend to provide generic meta information to the Depot client, and how is that meta information generated and handed to Depot prior to publishing the artifacts?
And secondly; Who should be responsible to define the classloader concern, expressed in generic meta information?
Since I suspect the answers to the above is "Not Depot's concern" and "Not Depot", then I am sorry to say that Depot future is very bleak, and I doubt it will receive any support from Avalon.
I hope the "not Depot's concern" stems from the lack of understanding the problem at hand, and that you will gain that insight sooner or later.
For me the target use case for depot has always been managing artifacts needed to build. So class loaders beyond setting a <path> resource in ant has never been a needed task.
Handling a chain of dependencies is something that we would like to do but it has never been a pressing concern. For the most part I scratch what itches, and jars for an ant build itches me all the time, so that is where I scratch. I understand some of what avalon is doing with downloading needed jars for an application server.
Here is the pieces of code I think can be useful to avalon.
* Version,
o Marking
o Comparing
o Computability,
* Downloading.
o Maintaining a local cache of jars
o Updating a local cache of jars
o getting the "best" jar available.
o mirrors
* Security
o verify md5 signatures
o verify other signatures.Having outside user of our API would be great. Our API has gotten really FAT and needs cleaning. If you are interested in investigating using our API I will be happy to help.
For the future of Depot, I think it is important to try to produce the smallest useful set of tools possible, not the biggest. Classloading is a real problem in java, and an important one to tackle but I prefer to keep the scope of Depot limited. Other project's like Avalon can tackle the classloaders. Perhaps we can take over the version/download/security stuff.
In a perfect world would would the depot API as used in your class loader look like ?
File theJar = depot.getResource("log4j","1.2", booleanGetDepenetedProjects);
?
The issue chained dependencies is important, and I think gump can be of assistance. However gump only reflects the current state and we need access to the dependencies for other versions as well.
So work on the Meta info is a place we can share efforts. But it is a goal for Depot to work, at least in a basic/default way WITHOUT any separate meta info.
What do you see as the common ground for us to participate on ?
R, Nick
