All, I did a quick review (and I say quick, so please correct me where I am wrong). This is what I found:
The Avalon codebase is simple -- and that is a major plus, no clutter, no fuss. The approach is nicely broken into separate source directories (which helps illustrate the separations) such as API, SPI (Repository Plug-In), Impl, Util. The fundamental classes are Artifact and Repository (which map directly to Resource and Repository in Depot, and are coded *almost* identically.) Basically, I see *immense* similarities -- starting with basic design approach & implementation choices. [One plus include similar coding style ... one less niggly 'discontinuity' for us to hold noses to, through with a merge.] I do see some Avalon code in there. I do see some 'Classloader' code (at lower levels, e.g. in Repository) and that we can discuss/negotiate over. I see some reference to security, but I'm not sure if that is Avalon security or JDK or whatever. I'd like to learn. In short, I see the same intentions/approaches, just minor (perhaps) implementation differences (e.g. API choices, Factory implementations, configuration, etc.) I think we can explore the pros and cons of each choice and select the better on a case by case basis. I remain of the opinion that we can import Avalon Repository into a classloader project, refactor it & run it over some Depot core classes. Those Depot classes would either be (originally) Avalon Repository classes, or would have the 'required features' merged into them. That core could be called 'Update' (as it is today) or we could split off a core (simply the layer that Stephen mentioned yesterday). As I see it Depot Update has most of what Avalon Repository has -- albeit cluttered/unclear (and not all completed nor needed.) I think we need to pick apart this code so that we have a lean/mean core -- not a cluster. I think the task of teaching the Avalon folks about the Depot codebase will really helps us clarify what we want/what we need and what we can trim. [When reviewing things yesterday I got clear (after many months) on all our pieces, and it helped me.] Here is what I see Depot Updater has in addition: - Protocol code over java.net.URL or HtppClient or VFS. [Which is loaded depends upon the environment. Might be a portability (over CLs) issue, might be cool.] - Ant Tasks/Types (and some Tools) [These are used by AntWorks.] - More commandline tools (for Gump etc) - Logging (listener abstraction, so we can plug in to Ant or CL or Avalon or ...) - Utility classes (File interface (creates Resources) to/from Updater..) - Monitoring (listener pattern, stats collectors, stdout loggers, etc.) Some higher level capabilities (based upon understanding the data): - Repository Queries (with Selectors/Comparators) - Version Parsing (and hence ordering, selection of 'best') [We can discuss if these out be in a separate project.] Some dodgy (incomplete) clutter: - XML Configuration system (albeit incomplete). - XML deserialization/serialization (albeit incomplete). [There was a rationale here, I can discuss in a separate mail.] Basically, I feel that the Depot code has a lot more -- but I think that has hindered it, rather than helped. Develops are lost in the internals before it is complete, and we need to remove the clutter. BTW: I see the biggest problem ahead as either picking a build system, and/or picking a hierarchy that all three can live with (Maven -- still needed, Magic -- wanted here?, AntWorks -- has source folder issues). I hope we can find a simple solution. regards, Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com