Hi Rajini I'm covering old ground here but trying to make sure I'm looking at this in the right way.
A - How closely class loading should be related to model resolution, i.e. options 1 and 2 from previously in this thread A1 (classloader uses model resolver) - standardizes the artifact resolution process but make classloading more complex A2 (classloader doesn't use model resolver) - simplifies the classloading process but leads to multiple mechanisms for artifact resolution B - Support for split namspaces/shared packages Supporting this helps when consuming Java artifacts in the case where there is legacy code and for some java patterns such as localization. I expect this could apply to other types of artifacts also, for example, XML schema that use library schema for common types. C - Recursive searching of contributions It's not clear that we have established that this is a requirement D - Handling non-existent resources, e.g by spotting cycles in imports/exports. It would seem to me to be sensible to guard against this generally. Is a specific requirement if we have C It seems to me that there we are talking about two orthogonal pieces of work. Firstly B, C & D describe behaviour of artifact resolution in general. Then, given the artifact resolution framework, how does Java classloading fit in, I.e. A1 or A2. Can we agree the general behaviour first and then agree javal classloading as a special case of this. Regards Simon
