On Monday 21 June 2004 13:04, Nick Chalko wrote: > 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.
Hmmm.... But it has been solved over and over, and to consolidate everyone's effort requires that something 'extra' is brought to the table. No? > 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. Ok, that is a fair point. But one can still be setting out on a "vision", and gathering some support around such vision, and some people may join in and help out. Scratching the itch is just what you do today :o) > I understand some of what avalon is doing with downloading needed jars > for an application server. Kind-of correct. Since the benefit is not for Avalon Merlin itself, but for our users. When they include a JarABC resource, it is very nice that they don't need to worry about that JarDEF, JarGHI and half a dozen others also need to be downloaded as a result of depending on JarABC. > * Version, > o Marking > o Comparing > o Computability, We are drawing closer to the conclusion that version should be a unique number, and basically eyeing the SVN number itself, as that is giving us the sideeffect of knowning exactly how to rebuild the artifact in question. > * Downloading. > o Maintaining a local cache of jars > o Updating a local cache of jars > o getting the "best" jar available. > o mirrors "best" probably means the 'Version Constraint' that I saw on the web site. I still have some mixed feelings about this, not by concept but the design/impl. > * Security > o verify md5 signatures > o verify other signatures. MD5 is not security, only a download checksum. Proper signature handling, especially now when ASF is getting a CA box up and running, is definately something good.... but otoh it doesn't exist yet, and we'll probably have that up and running too in Avalon Repository, before Depot has something useful in place (am I too negative? Sorry in that case.) > 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. The problem comes in when you introduce chained dependency. How do you signal that such a thing exist to the 'user' ? > In a perfect world would would the depot API as used in your class > loader look like ? Something like; Artifact artifact = Artifact.locate( "jar:avalon:avalon-framework", version ); ClassLoader cl = artifact.getClassLoader(); 'version' above is some form of version descriptor. This part requires some serious thinking. > 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. Gump?? Sorry, how on earth did you manage to get a "Continuous Integration System" to be part of a 'Jar Hell' solution? We have chained dependencies in place. It works well, but our down side is that only Avalon tools generate and understand the necessary meta information required to support this feature. > 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. Ok, that is not a problem. > What do you see as the common ground for us to participate on ? ATM, the biggest problem is that we; * Know too little about each other's concerns and view points. * Doesn't understand each other's codebases. * Disagree of the total scope of Depot. What _I_ really would like to do is move Avalon Repository to Depot as a sub-project, but there are some 'community problems' with that, i.e. Depot is in Incubator, and Avalon has said NO to depending on Incubator projects. Anyway, once Repository was in Depot, one could take out the bits and pieces that exist elsewhere in the Depot codebase. Cheers Niclas -- +------//-------------------+ / http://www.bali.ac / / http://niclas.hedhman.org / +------//-------------------+
